Thread: RE: [Cppunit-devel] ExtendedTextTestRunner
Brought to you by:
blep
From: Philippe F. <P....@OB...> - 2003-01-28 13:29:25
|
> From: Baptiste Lepilleur [mailto:gai...@fr...] > > CppUnit 1.9.10 already provides similar functionalities > through the generic TestRunner class. Hi Baptiste. If you are coding a new version of CppUnit, I have some suggestion for it. There are a few things that I dislike in CppUnit, which has lead me to code my own testrunner and assertions. I attach the files so that you can look at it. The differences with CppUnit are explained in the headers, which I copy here: /** * I wrote this class because I was dissatisfied with the text runner of * CppUnit. This works with CppUnit 1.8.0 I don't think it work with any other version. * * The goal of PhilTestRunner was for me to make the output of the testing * more readable and useful. It has the following characteristics: * * - it prints the name of the suite being run and separate two suites with a * blank line, so that you know better in which suite you are. * * - it prints the name of the test being run, so that when you have some kind * of debug output, you know to which test it belongs. * * - the failures are reported in detail while the suite still runs, directly * in the offending test. This differs from CppUnit which reports them at * the end. This is very useful if you have test suites that take a long * time. By placing the most offending test in the first position of the * suite, you don't need to wait for the whole test to finish before * spotting and understanding the failure. * * - on windows, the failures are also printed in the Debug window, using * OutputDebugString. This output is in the Visual C++ debug format, so * that pressing F4 (even during test run) sets your cursor directly on the * right line, in the right file. Very useful! * * - it prints a short but nice summary at the end, with the number of test * run, failed, and the percentage. * * The output of a run looks like this: --- suite TestFoo + testOne + testTwo d:\software\cppunit-1.8.0\testunitexample\testfoo.cpp(40) : Failure! Expected: 7, but was: 2. + testThree d:\software\cppunit-1.8.0\testunitexample\testfoo.cpp(45) : Failure! Uh uh, this test failed --- suite TestMyClass * * All you need to use in this class is the PhilTestRunner. Ignore the other * classes, there are only used within PhilTestRunner. I package * everything in one header file and one source file to make distribution more * convenient. * * To use the PhilTestRunner, just do like with any other runner : PhilTestRunner runner; runner.addTest( CppUnit::TestFactoryRegistry::getRegistry().makeTest() ); return runner.run( "", false, true, true ); * * * Send any comment, bug, suggestion, patch to ph...@fr... * */ and /** * This is a set of replacements for the default asserts of CppUnit. This * works with CppUnit 1.8.0 . Thank to the architecture of CppUnit, it * integrates seemlessly. * * The differences are: * * - my asserts are shorter and easier to type because I do not prepend them * by CPPUNIT_ and because I use mainly non capitalised letters. This does * not respect the convention that macros should be in capitalised letters * but it saves me a lot of pain, so it is worthwile. * * - the order of equality assertion is reversed, because it is more intuitive * for me to have the actual value before the expected one. So * CPPUNIT_ASSERT_EQUALS( 1, a ) becomes checkEquals( a, 1 ) * * - I display the name of the expression being tested inside the failure, not * just the value that did not match. * * - for int equality asserts, I display the int value in decimal and * hexadecimal * * - I support native string equality tests, which avoids the following * drawbacks of CppUnit: * * 1. With Visual C++, CPPUNIT_ASSERT_EQUAL( std::string("a"), "a" ) * won't compile because the it does not know which template to use. * * 2. If you do a * char * s1 = "abcd"; char s2[10]; strcpy( s2, s1); CPPUNIT_ASSERT_EQUAL( s1, (char *) s2 ); * CppUnit will report a failure with the unhelpful message : * * "Expected: abcd, but was: abcd." * * This is because CppUnit has unintuitively compared the two pointers * instead of comparing the strings. My functions know how to cast a * (char *) to a string * * * - when displaying an error with a string, my strings are in quote, so that * you can see precicely where it begins and finish. No more * your-strings-are-not-equal-but-you-do-not-know-why-because-you-have- * not-seen-this-naughty-space-at-the-end-of-one-of-them. * * - for string equality asserts, I support case sensitive and insenstive * check. * * - I support also a assertion to test whether a string contains another one, * with adjustable case sensitivity * * - if you define QT_DLL, I support tests on QString too * * * This list of macros available are : * check( assertion ) for bool * checkEquals( actual, expected ) for int, long, double, std::string, QString and char * * checkNotEquals( actual, notExpected ) for the same types as checkEquals * checkDeltaEquals( doubleValue1, doubleValue2 ) for double * checkIEquals( s1, s2 ) for std::string, QString, (char *) * checkContains( s1, s2 ) for std::string, QString, (char *) * checkIContains( s1, s2 ) for std::string, QString, (char *) * * Send any bug, comment, suggestion, patch to ph...@fr... * */ It would probably make sense to add this to CppUnit. I am probably not the only one who have felt these problems. I know my colleagues prefer to use my addition than the standard CppUnit way. I attach the files since they are quite short. Could all people here provide feedback ? regards, Philippe |
From: Philippe F. <P....@OB...> - 2003-01-31 12:20:37
|
> I appreciate your dislike of long, capitalized macros, but I do not > think polluting the namespace with lots of macros which look like method > calls is a good idea. It is certainly not a good idea, unless you know what are doing. I developed this for me only at the beginning, so I knew exactly what I was doing. > I believe CppUnit did that at one point in the > past until it was decided that was a bad idea. See > CPPUNIT_ENABLE_NAKED_ASSERT in include/cppunit/TestAssert.h. However, > perhaps that could be a feature rather than just for backwards > compatibility, so those who want to 'import' lots of unqualified > assertion macros can do so. If you define qualified names names for > your macros, eg CPPUNIT_PHIL_..., then you could add shorter macro names > protected by ifdef CPPUNIT_ENABLE_NAKED_ASSERT. Then everyone could use > your macros who does not want the short names, and others can allow the > short names wherever they want. Exactly. The point of my posting is not to include my contribution as is, but ask for inclusion of similar facilities. Naming the simple assert check() for example is a bad idea, the name is too casual. Maybe the sort asserts should be prefixed with cu. Anyway, I hope this gets considered for inclusion in the next release. regards, Philippe |
From: Gary G. <gr...@uc...> - 2003-01-28 17:13:00
|
I appreciate your dislike of long, capitalized macros, but I do not think polluting the namespace with lots of macros which look like method calls is a good idea. I believe CppUnit did that at one point in the past until it was decided that was a bad idea. See CPPUNIT_ENABLE_NAKED_ASSERT in include/cppunit/TestAssert.h. However, perhaps that could be a feature rather than just for backwards compatibility, so those who want to 'import' lots of unqualified assertion macros can do so. If you define qualified names names for your macros, eg CPPUNIT_PHIL_..., then you could add shorter macro names protected by ifdef CPPUNIT_ENABLE_NAKED_ASSERT. Then everyone could use your macros who does not want the short names, and others can allow the short names wherever they want. gary |