Hello!
2009/11/30 Alex <alex.lavoro.pro...@gmail.com>:
>> 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."
Thanks! I've searched here and there but looks like c2 went down in the
pagerank. Now i get the idea and it looks like it's more or less the same
modulo "java slang".
> In my opinion, the test suites should be able to be instantiated with
> parameters.
Hmm, I don't know if it's easily doable with current "macrology" for tests.
>> 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(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.
But you can create tons of small contracts with very few basic assertions and
aggregate them in bigger ones. And C++ functions can perfectly fit
into this design.
Moreover, it's even better to implement several complex contract
suites built from simple shared contracts:
template <typename T> void contract_a(T& v) { ...}
template <typename T> void contract_b(T& v) { ...}
template <typename T> void contract_c(T& v) { ...}
complex contracts:
template <typename T>
void complex_contract_all(T& v) { contract_a(v); contract_b(v); ... }
template <typename T>
void complex_contract_selective(T& v) {
contract_a(v); contract_c(v);
CHECK(v.something_specific==0);
}
> Furthermore,
> if I put all the check macros in the one big my_complex_contract(), I
> cannot know the 'name' of the failure test.
Nope. Since some time UnitTest++ has a global state, namely pointer to
"currently executing test" so CHECK_xxx macros will print test name in
case of problem (along with line information). Provided this, test
name +and "file:line" location will precisely show you failed test
name and locate violated contract.
Basically, you can use CHECK macros anywhere and test name will be correct*
>
> 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();
> }
1. Suites are implemented as namespaces it would be very hard to
"parametrize them".
2. Test::runWhatever() take no parameters also, so "another" TEST
macros would be needed.
3. One would need to make fixture classes copyable for this to work,
and not everyone want's to test only copyable classes.
4. One of big advantages of UT++ is that it allows "automatic" linkage
of test suites and tests. It is enough to "link in" some object file
with test and it appears on your test list, so i would propose
something like this:
TEMPLATE_SUITE(name, class_under_test) {
TEMPLATE_TEST(name) {
class_under_test foo;
foo.yell();
}
...
}
TEMPLATE_SUITE_INST(name, mytypes::Cat);
TEMPLATE_SUITE_INST(name, mytypes::Dog);
But still - I don't believe that it's reasonable to one create
universal "macrology" that would fit only few use cases for these so
called Abstract Tests/Suites.
Just think of "virtual interfaces" or maybe "generic interfaces",
calling convention for arguments (const? volatile? by ref, by pointer)
or who and where instantiates classes. This is application specific
enough, that one should design it's own infrastructure and engineer a
generic thing only and only if the natural, brute force way (let's say
that my original proposition was like this) become tedious and full of
boilerplate code.
(I am becoming more and more conservative, with years ... I admit it).
Best regards!
--
Zbigniew Zagórski
/ software developer / geek / http://zbigg.blogspot.com /
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
unittest-cpp-devel mailing list
unittest-cpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
