On Mon, Dec 29, 2003, Michael Nordstrom wrote: > I have added support for unit test using PalmCUnit.
Before a bug is fixed a test case should be added that can reproduce the bug. I'm aware that it won't be possible to do that for all kind of bugs, but when it isn't possible there should be an explanation in a bug note. That's correct, if you can't write a test case for a bug fix, then, if there isn't already one, you *have to* create a bug report so it is possible to track this problem. More developers involved in the viewer development means that the risk of us stepping on each other's toes increase ;-) With a good collection of test cases we can at least try to avoid breaking other parts of the code when we add some new code. It will also help in documenting the source code, since a test case will describe how to use the module it is testing (and it will also make us think about how the code in a specific module is interacting with other modules, i.e. improve the design). I will add new test cases before I make any changes to the code and I encourage all viewer developers to do the same. Anyway, for now you will only be "required" to do this for bug fixes. However, soon this will also apply when adding new features, since I would like to have a collection of test cases for every module in the viewer. BTW, it will be just as bad to commit code that breaks the build of the test version as making a commit that breaks the "normal" version. I have a cron job that runs every night building the viewer with several different config options, so that kind of problems will be found quite fast, but it's better if you try to build the viewer with a few different settings *before* you commit new code, e.g. if you add a some new preprocessor directive then please build the code both with and without this directive to make sure the viewer still builds. /Mike _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
