猫粮的菠萝阁 2010是自动化年

Here are the requirements for a good unit testing harness:

• a unit test harness must run very fast.
  • An example of what not to do is VS 2005's test harness - it takes about 3 seconds just to get going. Then it goes and writes large XML log files, which is extremely unfortunate, as one of the requirements of a good unit test is not to hit the disk.
• it must be extremely quick and easy to add a new unit test. Having to edit two files to add a single test is not acceptable.
  • Most C++ unit test harnesses fall down badly here: they often have a manual registration mechanism, where the test writer must register his tests in some fashion. This is unacceptable because if the test writer neglects to do this step, he sees no failures and may think everything is fine, but his test was never run.
  • This feature is called "Test auto-discovery" in " x Unit Test Patterns "
• a user must be able to select a sub-set of all the tests to run or to run a single test.
  • often you want to run just the one test related to the code you're writing right now. This is especially true if you've written so many tests that it takes longer than a second or two to run them all.
  • Most .Net-based test harnesses allow you to group by test class; some add also an attribute for grouping. Ideally, you'd like to be able to group more deeply than just all the tests, all the tests in a test class, or a single test (i.e., 3 levels). One very natural grouping mechanism is namespaces.
• it should be object-based:
  • there should be test setup and teardown methods (a.k.a. test initialize and test cleanup methods), that are run before and after each test. Also, there should be class initialzation and teardown methods, that are run once before all the tests in a test class and after all tests in a test class are run.
  • it should allow easy refactoring of the unit tests. If it's not OO-based, you often end up with C-looking test code, especially after refactoring the tests for a while. It would be a shame to have nice OO source code, but ugly non-OO test code.
  • it must support the self-shunt pattern
• it should be as light-weight as possible.
  • In C++, linking in .dlls or .libs (of the test harness) is a not ideal. Why? Because the environment that the test harness writer built the .dll or .lib for may not be compatible with that of a test writer. Ship the source to the harness and make it easy to build.