• 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
    Run each test*() method
      Run setUp() method
        Each test method consists of 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
• Seperate pure computation from database or file access
• Rather than have f() use g() which uses h(), consider flattening the call-tree: f() calls h(), and then calls g(h).

• Boolean or enumeration: test all possiblities
• Integer: identify equivalence classes, test one value in each class, or test both sides of each class boundary
• Reals: equivalence classes, plus test minor deltas for accuracy
• String: empty, multiple character classes, short and long, same as other strings or different
• Dates: boundaries, past/present/future, multiple formats
• Complex objects: break them down into smaller values, e.g., consider a Point to be an X and a Y
• Anything: make sure to include both valid and invalid values
• Anything: make sure to include both reasonable and unreasonable values
• Combinations of parameters: equal, unequal, related, unrelated, pointers to the same objects

• Look at the condition of each branch
• Decide what variable value would be needed to make it true or false
• Work backwards to find a test input that achieves those variable values