Tips on JUnit style
See also JUnit FAQ.
    For novice testers
    Each test MUST have an assert.  A method without an assert is
    not
    a test.
    
    The convention for using JUnit asserts is that the first
    parameter is the EXPECTED result, and the second
    parameter is the actual result.
    
    To make your intent clear, use assertEquals() when
    comparing
    results from a value-returning function. Use assertTrue()
    when verifying boolean functions. 
    
    Use the message argument so when your test fails it gives a
    meaningful
    message.  If you do this you don't have to include a comment
    explaining what the test does.
    
    Keep tests independent of each other.  Ideally only one test
    should fail at a time.
    
    Keep test methods small.  Purists argue that each test case has
    a single
    assert.  Pragmatists allow more than one assert as long as they
    all relate to testing the same behavior.
    
    Avoid System.out and System.err in your tests.  Tests should be
    automated and not rely on visual inspection of output by a human
    tester.
    
    Design your application in a manner that makes it easy to test.  Separate your user interface classes from your business logic. 
    This will make the core logic easier to unit test, because the
unit test doesn't require manual user input.  
    
    Don't make your methods rely on System.in.  Instead pass in a
    Reader and create a Scanner from that.  Here's a demo
      project to illustrate the technique.
    
    For Advanced testers
    
    Create small, focused interfaces to your classes to make it easier
    to
    create and maintain "mock" implementations.
    
    Avoid testing against databases and network resources (e.g.
    sockets).  Use an interface and a mock.
    
    Add a main() method that runs the test in TestRunner.
    
    Start by writing what you are testing: the assert.  Then work
    backward and fill in whatever is needed to set things up for the
    assert.
    
    Always write a toString() method in the class being tested
    to
    improve failure reporting.
    
    
    Create your test hierarchy around what the code does, not how it is
    structured.  
Write tests for behaviors, not methods.  A
    test
    method should test a single behavior.  
    
    Refactor your tests!  Avoid duplication of code in your tests
    as
    well as in the production code.  
    
    TestCase is a mechanism for fixture reuse. So if you have a
    VideoList
    class, create separate TestCases for testing empty list behavior and
    testing full list behavior; TestEmptyList and TestFullList. 
    (You'll also want OneItemList and a FullMinusOneItemList test cases
    -
    boundary value analysis.)
    
    Don't put tests in same folder has code being tested - put in a
    subpackage or parallel package.
    
    Run a coverage tool often to see what you might be missing.
    
    There should be at least as much test code as production
    code.  1.5 times as much is better.
    
    
    See also the JUnit FAQ.