CS384 HW#3

Due: Monday Feb 6, via svn/hg repository electronic committal
This is a team assignment. Place your work in doc/384-hw3.html, along with any auxiliary files or edits to existing files that you need to do.

In addition to briefly reporting your sprint's goals and how you did on them this Friday, please:

  1. Writing code bodies for your team's classes.
  2. Develop a test plan
  3. Discuss in Monday's report, what your first demo-able functional delivery and its milestone date is
  4. Demo for Monday, an example/prototype test case, with its 5 components

Part 2: Test Plans

1. Develop a test plan for your project. Meet within your team, divide the labor, and form a plan for testing all use cases and/or program functions over the coming weeks.

2. Use an automated test tool (such as JUnit, PyUnit, CppUnit) to develop a set of unit tests for each of your team's classes, which tests instantiation and each of the public methods in your class. Write white-box tests to verify functionality for typical and boundary-case inputs and program states relied on by your methods.

Unit Testing Step by Step

You are requested to do the following exercise (translating instructions as needed for the unit testing frameworks used with your implementation language(s)) as practice preparation for HW#2, adapting to your project language as applicable. It is NOT a graded turnin requirement, but if you have trouble or questions doing your unit test for the class project, I am going to want to see your work on this exercise.
  1. Download JUnit 4.4 for your development platform, if you do not have JUnit already.
  2. Set your CLASSPATH environment variable so it can find JUnit. For example, on a CS Lab machine, you might Add the following line to your .cshrc file: 
       setenv CLASSPATH .:/net/faculty/jeffery/junit4.4/junit-4.4.jar
  3. Read the Junit documentation at
  4. Read Yonggang Lu's Junit howto
  5. Write a unit test suite for the following "dummy" class. These are supposed to be complex numbers, with standard mathematical behavior as per the following definitions of addition and subtraction, multiplication, and division. . Your unit test suite should test whether created objects behave in a "sane" manner, i.e. whether the constructor and methods behave correctly. Is there a bug here? Verify it by testing, rather than simply staring at the code as you usually would. :-) 
    public class Complex {
double re, im;

  public Complex(double r1, double r2) {
   re = r1;
   im = r2;
  }
  public double real() {
    return re;
  }
  public double imaginary() {
    return im;
  }
  public Complex add(Complex c) {
    return new Complex( re + c.real(), im + c.imaginary());
  }
  public Complex subtract(Complex c) {
    return new Complex( re - c.real(), im - c.imaginary());
  }
  public Complex multiply(Complex c) {
    return new Complex( re * c.real(), im * c.imaginary());
  }
  public Complex divide(Complex c) {
    return new Complex( re / c.real(), im / c.imaginary());
 }
}
  6. Write a unit test suite for two of the classes from your project. Choose different classes than your team members so we don't duplicate efforts here. For each class, your tests should construct instances of that class and then, for each method, write tests for that method. Check method parameters. Try to get basic statement-block coverage, i.e. have tests that execute each line in the method at least once.
  7. Add your test suite to SVN.
  8. Merge your unit test suite with the rest of the class to form a "comprehensive unit test".
  9. Add a makefile entry for an executable that does the unit testing, this goes at the bottom and should not affect our regular project build. Check it into SVN.