If, in the setup method of my test class, I'm doing some check to see if different ressources or files are present and that those checks fail. It is possible to cancel all the test of this class?
I know, I can 'simulate' ressource or file with fake object (also called Mock object I think), but for now my work doesn't focus on this.
Thanks a lot.
Nic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want to do some setup, then run many test cases, then do one teardown. When I use a test fixture and CPPUNIT_TEST() macro, each test is a separate object, with setup and teardown called on it individually. I understand that this design was done to minimize interaction among tests. But I cannot use this, because my setup takes a long time.
I can hack it with a static function in the test fixture, or a singleton, but I thought there would be a more natural way.
Thanks for your help,
Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If, in the setup method of my test class, I'm doing some check to see if different ressources or files are present and that those checks fail. It is possible to cancel all the test of this class?
I know, I can 'simulate' ressource or file with fake object (also called Mock object I think), but for now my work doesn't focus on this.
Thanks a lot.
Nic
You can use assertion in setUp and tearDown. setUp & tearDown are always called, but the test run is skipped if setUp failed.
Baptiste.
Ok, but it appears that setup and tears down are call before each call to a test function of the class, am I wrong.
Because, for example, if my test class has 3 functions, the assertion in setup is shown 3 time in the mfc test runner.
Is there a way to avoid that and have only one assertion for the class?
thanks.
Nic
I want to do some setup, then run many test cases, then do one teardown. When I use a test fixture and CPPUNIT_TEST() macro, each test is a separate object, with setup and teardown called on it individually. I understand that this design was done to minimize interaction among tests. But I cannot use this, because my setup takes a long time.
I can hack it with a static function in the test fixture, or a singleton, but I thought there would be a more natural way.
Thanks for your help,
Tony