I try your test framework with some tests for my company software and found that the way they are launched in the testrunner (with ActiveTest) can arise problems : we use DAO and no test pass. If I use the test framework I made (wich is like your one, but lightweighted. I apology, your work is very fine and well coded, but does not comply with my company need), wich first does not use any thread, they all pass. If I add the threads, they fail.
So, the question is : why do you use a thread, for security or performance ?
For those reasons, I've begin a VCUnit, which probably does not comply with Beck white papers, but it works fine. As my company works with VStudio, I also add a way to display the failure file and line, to make corrections easily. The ProgressBar can be of interest for your unit. If you want to see my work, let me know and I'll post a zip file for you.
Your work was very a good source and "schollar".
Sorry for my poor english, I'm french.
The thread is a legacy from Michael Feather's version. Since the test are running in a separate thread, you can still use the GUI. It would also be an optimisation if the progress bar repaint was done in the GUI thread instead of the testing thread (a lot of time is lot painting the progress bar).
Considering your problem, DAO most likely need some setup/shutdown in each using thread. You can to that in the setUp/tearDown methods of your TestFixture.
I had a similar issue at work each thread need to register to a manager to be able to use the database. I solved this by subclassing TestCase and implementing the correct initizalition/clean up sequence in setUp/tearDown. This class is used as a base class for all our unit tests.
Fell free to send me your work if you think it can be interesting.
PS: I'm French, by the way...
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.