|
What is TUT?
TUT is a small and portable unit test framework for C++.
How does it differ from C++Unit (boost::test, ...)?
C++Unit and boost::test perform similar tasks, and, frankly, sometimes you can use them for the same purpose even with better results. But there are two issues with the both:
1) they require a library (and building one is not easy on some platforms)
2) registration and test running depends on the preprocessor macros, and that makes the code hard to read.
TUT, in contrast, is located in a single header file (20K). So, all you should do is to include it into the test module. No linking at all.
TUT uses C++ template engine to dispatch calls to test methods. Therefore you shouldn't even register methods: template will do it for you automatically. As a result, the test code will be readable, because you read the code itself, not macros.
And finally, TUT is a minimal software; it only does what it's designed for. It doesn't attempt to integrate with MSDN or to control the running production processes; it just runs tests.
Which compilers are known to be supported?
Some outdated compilers are unable to handle templates in TUT, but most
of modern ones are able.
Able to use TUT:
- GNU GCC 2.95
- GNU GCC 3.x (both under unix and MinGW)
- Borland 5.6 (Borland C++ Builder 6)
- Intel C++ Compiler 6.x
- Microsoft VC7 (Microsoft VS.NET 2003)
- Sun WorkShop 6 update 2 C++ 5.3 (probably, previous versions as well)
Unable to use TUT:
- Borland 5.5.x (Borland C++ Builder 5)
- Microsoft VC6 (including SP5)
- Microsoft VC7 (Microsoft VS.NET 2002)
If you do use TUT with any other compiler or environment, please, let me know.
I've taken a look at the selftest code and it looks awful
Never mind. Self tests are very special beasties, and actually you've seen
two(!) TUT frameworks running one under control of another. The case is
quite extreme, regular TUT tests are very simple to read; you'd better look
at the example directory or online example.
Why don't you provide methods to catch user-code exceptions?
First of all, the user-code exceptions are intercepted inside the test runner, and afterwards user receives them along with the test_result status. For std exceptions, a textual message is included into results. For the others there will be a message, reading that an unknown exception was generated. (There are plans to provide users with template traits for filling type lists with possible exception types.)
But, TUT doesn't attempt to somehow mark the exact line where the exception's happened (as other C++ frameworks do with the macros like TEST_EXCEPTION). The reason is C++ itself doesn't support this information. Exceptions may arise in the user code ten levels below, but stack trace is not stored, so to get the exact line where it's happened in the test method would be of little or no use at all. Instead, you'd better provide well-describing messages for your throwed exceptions.
In other words, TUT will not attempt to emulate features that shall be implemented by the language itself.
I've used ensure_equals() method and compiler refused to build my code complying that there is ambiguous overload for operator <<.
One or both types you've provided to ensure_equals() have no operator << at all. Since the diagnostic message is built using std::stringstream, compiler needs the operator to format your objects. Either provide it (it's a good idea anyway) or use ensure() method (which doesn't tell you the exact values the objects had, just the fact they were not equal).
What about segmentation faults in code being tested? What about deadlocks?
C++ Standard doesn't specify what happens if the code references
wrong address. Thus, segmentation fault processing
is system and compiler dependent,
and shall be handled differently in each system/compiler
pair.
If you want TUT to react correctly to tests failures caused by segfaults,
you must to configure your binary to raise an exception in case of
SIGSEGV or Segmentation Fault.
For Win32 TUT uses SEH, so you'll need not perform any special steps
except to specify -DTUT_USE_SEH at build time.
For Linux and g++ this code works (NB: this is non-standard and can
change with any OS/compiler release):
void signal_to_exception(int)
{
throw std::runtime_error("killing signal catched");
}
int main()
{
signal(SIGSEGV,signal_to_exception);
signal(SIGILL,signal_to_exception);
...
}
More portable way is to use restartable wrapper defined in
optional header tut_restartable.h. It runs the tests the same way
as regular runner does, but also logs any test it going to
execute. If test crashes test application, and then test
application runs again, it will load last log record, and
continue test execution from position after the crashed test.
Of course, this requires helper script that runs test application
until all tests will be runned. The script is as simple as
while true
do
./restartable && exit 0
done
Directory examples/restartable contains simple restartable test application.
This approach can be extended to support deadlocks in code. The script
must be modified to automatically kill test application after specified
period of time.
|