Project Development Notes:


These notes are based upon observations of the code being developed.

Since the Tests are supposed to be driving the design, the test code is very important. Strive to keep it from getting smelly.
A reader of the test code should gain insights into the function of your model. The tests serve as a guide to how to call model methods and what results are expected. Use meaningful names for your tests (and for methods, constants etc. also in your model). You may certainly create helper methods in your tests especially if you find yourself repeating similar code in multiple tests (Extract Method).

  1. Use setUp when appropriate. If your tests require similar initializations, let the setUp method do it. If you find yourself with multiple groups of tests, divide into multiple TestSuites and add appropriate build target to your build.xml file.
  2. Use assertTrue, assertFalse where appropriate (don't always use assertEquals if there is a better option).
  3. Model class(es) should not know about the tests or about Mock objects. We want to test the actual model code that will be used in production.
  4. Sometimes tests force the introduction of additional methods (or make some methods public) to retrieve internal status from the model. To some degree this may have to do with style. It can be argued that tests can be written for a higher level but often providing the additional functions has the effect of making the code more modular, helping to drive the design in a beneficial way. Do not simply make the model's internal data structures public.
  5. Tests should truly test the model's logic. Test what might go wrong. Simple set flag/get flag tests are usually not very useful. Instead you might: verify state, ask the model to do operations (doRoll, doMove(loc), ...), get state and compare with expected. Here the test compares the expected change in state to what the model does after a sequence of operations.
  6. Keep as much logic as you can in the model. If your view/controller get too complex, you have compromised the MVC paradigm. Complex behavior in the VC (gui) is generally not as easy to test as the model. You may also end up duplicating (often incorrectly) behavior/assumptions in the M and elsewhere. During testing, there is also the problem that the test logic can get too complex.
  7. If your test merely directly sets and gets state (flags etc.)  in the model it is not testing the logic of the model - your tests lack depth and are incomplete. Check the deeper logic of the model and more of its state (are the pieces in the expected locations etc.)
  8. A bug in the model  is a good indication of the need for a new test. (For example, you test the crash feature and implement it w/o regard to safe squares. Later a "bug" is discovered because a crash should not occur on a safe spot. Write a test for that situation as well).
  9. Follow coding conventions - in test and GUI code as well as in the model. Common violations are: improper indenting, variableNames, CONSTANT_NAMES, poor names that don't convey the real meaning, inconsistent names, literals)
    For instance, what does value = getPawn(1,3) mean?
    How about expectLoc = getPawn(RED, PAWN3) ?
  10. Tests serve as an example of how to use the model - write clearly using meaningful names. Add comments to explain special situations especially for more involved tests (simulated game play)
  11. Remember to add javadoc comments to your model classes.