class HtmlLinkRewriterTest ... {
    void testAppendsAdditionalParameterToUrlsInHrefAttributes(){?}
    void testDoesNotRewriteImageOrJavascriptLinks(){?}
    void testThrowsExceptionIfHrefContainsSessionId(){?}
    void testEncodesParameterValue(){?}
  }

This can be read as:

 
   HtmlLinkRewriter appends additional param to URLs in href attrs.
   HtmlLinkRewriter does not rewrite image or JavaScript links.
   HtmlLinkRewriter throws exception if href contains session ID.
   HtmlLinkRewriter encodes parameter value.   

Benefits

The tests emphasizes the object's responsibilities (or features) rather than public methods and inputs/output. This makes it easier for future engineers who want to know what it does without having to delve into the code.

These naming conventions can help point out smells. For example, when it's hard to construct a sentence where the first word is the class under test, it suggests the test may be in the wrong place. And classes that are hard to describe in general often need to be broken down into smaller classes with clearer responsibilities.

Additionally, tools can be used to help understand code quicker:

(This example shows a class in IntelliJ with the TestDox plugin giving an overview of the test.)

Remember to download this episode of Testing on the Toilet, print it, and flyer your office.

 def Foo(path):
   if os.path.exists(path):
     return DoSomething()
   else:
     return DoSomethingElse()

 def testFoo(self):         # Somewhere in your unit test class
   old_exists = os.path.exists
   try:
     os.path.exists = lambda x: True
     self.assertEqual(Foo('bar'), something)
     os.path.exists = lambda x: False
     self.assertEqual(Foo('bar'), something_else)
   finally:
     # Remember to clean-up after yourself!
     os.path.exists = old_exists

Congratulations, you just achieved 100% coverage! Unfortunately, you might find that this test fails in strange ways. For example, given the following DoSomethingElse which checks the existence of a different file:

 def DoSomethingElse():
   assert os.path.exists(some_other_file)
   return some_other_file

Foo will now throw an exception in its second invocation because os.path.exists returns False so the assertion fails.

You could avoid this problem by stubbing or mocking out DoSomethingElse, but the task might be daunting in a real-life situation. Instead, it is safer and faster to parameterize the built-in:

 def Foo(path, path_checker=os.path.exists):
   if path_checker(path):
     return DoSomething()
   else:
     return DoSomethingElse()

 def testFoo(self):
   self.assertEqual(Foo('bar', lambda x: True), something)
   self.assertEqual(Foo('bar', lambda x: False), something_else)

Remember to download this episode of Testing on the Toilet, print it, and flyer your office.