On Mon, Nov 30, 2009 at 5:59 PM, Alex <alex.lavoro.pro...@gmail.com> wrote: > 2009/11/30 Zbigniew Zagórski <z.zagor...@gmail.com>: >> 2009/11/30 Alex <tzuchien.c...@gmail.com>: >>> I know this topic has been discussed before. I've read the previous >>> posts and if I understand correctly, UnitTest++ is not designed to >>> support abstract test cases/suites. >> >> The "abstract" world is not as well defined in C++ world as in Java. >> What does it mean abstract in test? >> >> Is the abstract test, something more than "parametrized test" intended >> to be reused with various implementations ? > > >From http://c2.com/cgi/wiki?AbstractTestCases: > "An Abstract TestCase is a TestCase for an AbstractClass that ensures > that concrete implementations of the abstract class behave as > expected." > > In my opinion, the test suites should be able to be instantiated with > parameters. > >> If that's it I would go into this direction ... >> void my_complex_contract(SomeInterface& object_under_test) >> { >> SOME_CHECK(someValue, object_under_test.GetSome()) >> ... >> } >> >> TEST(PersonImpl_follows_my_complex_contract) >> { >> PersonImpl p; >> my_complex_contract(p); >> } >> >> TEST(Department_follows_my_complex_contract) >> { >> DepartmentImpl p; >> my_complex_contract(p); >> } > > I don't have a complex contract but instead a lot of simple contract. > So one big my_complex_contract() doesn't seem good to me. Furthermore, > if I put all the check macros in the one big my_complex_contract(), I > cannot know the 'name' of the failure test. > > Instead, I expect something like this (pseudo-code): > > SUITE(EditorTest) { > TEST(OpenFile) { > editor.open("test.txt"); > } > TEST(SearchAndReplace) { > editor.search_and_replace("foo", "bar"); > } > /* ... a lot of test case here ... */ > } > > class NotepadFixture {}; > class EmacsFixture {}; > > int main(int argv, char* argv[]) { > AllTestList.addTestSuite(EditTest(NotepadFixture())); > AllTestList.addTestSuite(EditTest(EmacsFixture())); > return RunAllTests(); > } > > I am curious that why UnitTest++ was not designed to have per-suite > setUp and tearDown ? > > Alex.
AFAIK the abstract test paradigm is basically used to ensure that the Liskov Substitution Principle is not violated. Although I think that needing to rely on the LSP except for Adapters / Proxies is a smell for duplication. I understand the rationale behind it, but if it behaves the same, it is the same. To do want you want with UT++, you basically instantiate an instance of your class in every test and delegate the actual testing to a second function. This can then also be done with all other classes. Basically as Zbigniew said, only I would do it in a smaller granularity... The reason for not having suit wise setup and tear down is that it does not make sense. Every test is to run in isolation and suit wise setup and tear down breaks that. If you mean that these are setup and called for every test, then you can use simple inheritance with your fixtures. All fixtures in your suite inherit from one master fixture. Sean ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ unittest-cpp-devel mailing list unittest-cpp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
