Test Setup And Tear Down

When I use CeePlusPlus, I often add an empty TestCase that I Name TestSetupAndTearDown in the beginning of the TestSuite, to validate the setUp() and tearDown() methods. I think I started this when I introduced a problem in the tearDown() method that caused the next TestCase to fail.

Do you HaveThisPattern or, in the opposite, do you see any drawback to this?

Why did the next test fail?

Myself, if I need to have a teardown method, I try to make the setUp method fail if the tearDown didn't finish its job. This way, although the next test will still 'fail', it'll be obvious from the stack trace that it was something wrong with the setup. In other words, what happens if the tearDown fails because of something in the test? Your tearDown test won't catch it, and it'll look like the next mysteriously test failed. If you make the same assertions in the setup code, the nature of the error is quick and easy to see.

-- WilliamUnderwood

I can't remember exactly; I think it was some nasty memory management problem. Another time it was the tearDown() method that I broke. The reason why I added this empty TestSetupAndTearDown TestCase is because I looked for the source of the problem in a TestCase and in the tested code while it was in the setUp() or tearDown() method. The empty TestSetupAndTearDown TestCase allowed to IsolateTheProblem?.

The problem is that, with CppUnit, there is one test case object per TestCase in the suite. But if I ran into this trouble, it might be cause my TestCases? were not enough isolated. I recall adding an empty TestSetupAndTearDown method that failed, highlighting the problem. Once the problem was fixed, I decided to keep it, starting a new habit in my ProgrammingPractices?.

I also used the TestSetupAndTearDown method to assert on the setUp(), to be certain it is exactly what I expect it to be. --PhilippeAntras

---

CategoryTesting