• Usually for unit testing, but it could be used for larger tests too
• "Framework" means that it is a set of abstract classes that you subclass
• "Regression" just means that the tests can be kept throughout the project and run frequently

• Assume you are testing class C.java with methods m1() and m2(), and class D.java with methods m3() and m4()
• Create class TestC.java with methods testM1(), testM2(), testM1M2(), ..., and TestD.java with methods testM3(), testM4(), .... Each test class is a subclass of JUnit's TestCase class.
• Each test class exercises one class in the system. Each test method exercises one method in the system. You also write additional test methods to exercise combinations of system methods.
• Each test method consists of a sequence of steps, and some checks of the results.
• Once you have the unit tests written, you run them. You could run them directly from main(), but it is easier to use a test running utility, e.g., the JUnit TestRunners or the Ant junit task.

• Test runner is given a list of test classes
• For each test class:
    Create an instance of the test class
    For each test*() method
      Run setUp() method
        Run test method steps and checks
        If a check fails, an assertion is thrown and the test method fails
      Run tearDown() method
• Test runner produces a report
• Some test runners work interactively

• Product: name and price. Product.java
• Shopping cart: collection of products, calculates total. ShoppingCart.java
• Shopping cart: collection of products, calculates total. ProductNotFoundException.java
• Test class: tests shopping cart. ShoppingCartTest.java

• The order of the test methods is not determined
• setUp() method makes some variables that are used in the tests
• tearDown() frees memory, prevents results of one test from affecting the next
• Checks are done with assertEquals(), assertTrue(), etc.
• Test checks that assertion is thrown by calling fail() if it is not thrown, and silently catching it if it is thrown
• Missing test cases: a new cart should be empty, add the same product twice, remove a product that was already removed, test isEmpty(), etc.

  <target name="test" depends="compile-tests">
    
      <mkdir dir="${testreportdir}"></mkdir>
      <junit dir="./" printSummary="yes">
        <batchtest todir="${testreportdir}">
          <fileset dir="src/test/java">
              <include name="**/Test*.java"></include>
          </fileset>
        </batchtest>
      </junit>

   </target>
  

• Developers would run this before they commit changes
• The team might run this every night automatically

• Seperate logic that can be automatically tested from logic that requires human judgement
• Separate pure computation from database or file access
• Place classes into packages that can be tested independently or in layers
• Flatten the call-tree: rather than have f() call g() which calls h(), consider having f() do x = h() and then call g(x). That makes g() more testable.

• Try to cover all possible input values
• It can be useful to force the system to generate specific outputs
• Make sure that you know the corrected expected output
• Measure coverage and improve it by adding test cases or additional input values