On 1/29/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I ran into a problem with some of the unit tests last week and ended up having to do more work than I wanted to in order to figure out what was wrong and how to fix it. Part of the problem I had to solve was working around some quirks in the way the unit tests run and after doing so I am currently of the opinion that we would be better served to make some adjustments to the way the unit test code is currently layed out.
... etc. ...
So, based on these issues I would like to make a few changes/recommendations on how the unit tests are written moving forward ... 1. Write small and concise tests. You should not be writing much (if any) setup/teardown logic inside your test. If you are then it should be moved out into the setUp() and tearDown() methods. 2. Don't lump all tests into a single file. Just because a group of tests are all related to testing functionality of weblog entries doesn't mean they have to be in the same file. Separate out tests into multiple class files particularly based on the setup and teardown needs of the tests being run. If you are trying to add a test to a file which already has setUp() and tearDown() methods which don't fit your needs, then put that test into a new file. 3. Don't throw exceptions from the setUp() and tearDown() methods. Catch those exceptions and log them properly so that the error can be quickly fixed. 4. Add logging messages to indicate the BEGIN & END of each test. This makes it *soooo* much easier for someone crawling through the log file to tell exactly what has been happening and where. do all those things make sense?
+1 I think you've correctly identified (some of the) problems with the unit tests and all 4 of those recommendations make sense. The thing that bugs me the most is when a test fails, tearDown fails and you then get a string of usernameInUse errors for the rest of the tests instead of valid test results. - Dave
