CUTE provides macros for comparing for inequality that will populate the nice diff view in the plug-in with the values compared. Look for example at the following test:
void test_cute_assert_greater_equal_success() {
int const x = 4;
int const y = 4;
ASSERT_GREATER_EQUAL(x, y);
}Other examples are:
The CUTE Eclipse Plug-in results and diff view.
Write table-driven tests that tell you the location of the table input in addition to the tests function name. Clicking on a failed test will put you into the table entry that caused the failure. If everything works fine, you end up on the table-interpreting function.
struct testInputData {
double input;
double expected;
cute::test_failure failure;
} const dataTable [] = {
{ 4 , 16 , DDT() },
{ 2.5, 6.25, DDTM("compare well?") }
};
double square(double x) {
return x * x;
}
void test_cute_data_driven_equality_demo() {
for (auto const & testEntry : dataTable) {
ASSERT_EQUAL_DDT(testEntry.expected, square(testEntry.input), testEntry.failure);
}
}
Rerun a selected test in the CUTE Eclipse Plug-in.
Run or rerun single tests by providing a suite name, a hash symbol # and the test name as arguments to the command line. For example:
$ cutest 'AllTests#thisIsATest'Of course, the Eclipse plug-in provides a more convenient method to rerun failing tests.
CUTE creates XML files named like the test program. If you pass argc as zero, the filename will be testresult.xml. This makes it more convenient to put your test executable into the build process of a build server that expects JUnit-compatible XML format, such as Jenkins.
<testsuites>
<testsuite name="AllTests" tests="2">
<testcase classname="AllTests" name="thisIsATest">
<failure message="../src/Test.cpp:7 thisIsATest: start writing tests">
thisIsATest: start writing tests
</failure>
</testcase>
<testcase classname="AllTests" name="thisIsAnotherTest">
<failure message="../src/Test.cpp:11 thisIsAnotherTest: start writing tests">
thisIsAnotherTest: start writing tests
</failure>
</testcase>
</testsuite>
</testsuites>This is an experimental feature to allow running CUTE tests using ASSERT_EQUAL to run on limited hardware, where using iostream for numeric conversions is too expensive. If you compile your CUTE tests using...
#define DONT_USE_IOSTREAM 1...respectively the compiler command-line setting of the macro with "-DDONT_USE_IOSTREAM=1" then CUTE shouldn't include iostream headers. However, you might need to adjust your main function or runner as well, for example, to pass the output of the tests over a serial line instead. Feedback on the feasibility of that feature is highly welcome.
