T2C (“Template–to–Code”) tools generate the sources of the tests as well as makefiles (and other files nesessary to build and execute the tests) based on special templates. In the most simple case, the templates are little more than “documents with holes” where T2C file generator inserts the blocks of source code and other data provided by the test developer.
By using template-based file generation, T2C technology allows to separate the logic of the tests from the features specific to the particular testing framework being used. From the point of view of “Model-View-Controller” paradigm, parameterized test scenarios containing the logic of the tests can be considered as a “model” while the templates used to generate the final source files are related to the “view”. This allows the test developer to concentrate mostly on what the tests should check and how rather than on how to get them work with GLib Testing Framework, TETWare, CppUnit or any other testing framework.
The idea of template-based test source generation and enforcement of model-view separation was inspired by Terence Parr's articles and his StringTemplate system. Although the template engine used in T2C is great deal less powerful than general-purpose systems like StringTemplate, it provides all main features that have been necessary to use it in test development so far.
Note
The templates used in T2C technology should not be confused with the templates that C++ language provides. These two notions are unrelated. The latter templates are the constructs used in C++ code while the former templates are “documents with holes” that define how the final source code of the tests for the chosen testing framework will look like. Of course, T2C templates can be used to generate source code in C++ whether this source code contains C++ template classes and functions or not.
T2C technology allows to create the tests for different target testing frameworks from the same set of parameterized test scenarios provided in a .t2c file. This can be done by using different sets of templates and probably different implementations of T2C API (a small number of commonly used functions and macros).
Currently the following file generation targets are supported by T2C (all of them are for C/C++ although T2C allows to generate files in other languages as well):
- c_tet
A target for TETWare Lite testing framework by The Open Group
- c_gtest_nested
A target for GLib Testing Framework by GNOME community
- c_standalone
A target for a simple testing framework provided with T2C. It can be handy when using a full-fledged testing framework is undesirable for some reason. For example, you may wish to integrate the tests you have developed into an existing test suite that uses its own test harness and you do not want to make the suite depend on any other testing framework. After building the tests prepared for c_standalone target, you will obtain a collection of the ordinary executable files, each of which implements a group of tests. These executables will not depend on any external testing framework, they will have everything they need built in, hence “standalone” in the name of the target.
- c_minimal
A target that allows to create an application that contains little more than the test functions generated from parameterized test scenarios provided by the developer. The goal here to provide just a plain C/C++ source containing these functions and a makefile for it. Therefore a lot of features available in the other T2C targets are not supported here. Among these are requirement-related facilities, execution of the tests in separate processes, time limits on test execution, logging of test output, etc. The resulting (“minimal”) application can be used for the following:
Debugging of the developed test scenarios. It is not always easy to debug the tests that use a full-fledged testing framework: it may execute the tests in a separate process each, it may meddle with signal handling or even, in some cases, intercept system calls made by the test, etc. All of this may affect the operation of the debugging tools. What is typically needed however, is just to debug the test scenario that the developer has prepared rather than the operation of the chosen testing framework. If this is the case, c_minimal can be helpful.
Investigating the behaviour of the system under test. Sometimes it is beneficial, especially if the developer suspects that the system under test might behave wrong in certain conditions but the test itself does not catch it.
Preparing the example programs that demonstrate the errors found by the tests. The system under test may have been developed by a completely different team than the test suites for the system. When opening a ticket in a bug tracking system concerning a problem found by the tests, it is often desirable to provide an example program that demonstrates the problem. If the example used some advanced testing framework, it could be more difficult for the developers of the system under test to understand, build and execute the example. A plain source file (perhaps with a makefile) is what they often need.
It is not required for a developer to use any of the above targets and the mentioned testing framework. The targets can be developed for other testing frameworks too. This way T2C technology and tools can be integrated with these frameworks, giving the developer the best of the both worlds: the benefits from the chosen testing framework and the features of T2C that facilitate development of functional tests.
Note
The T2C targets listed above are designed for Linux operating systems. The targets aimed at the testing frameworks that run on other operating systems (e.g. Microsoft Windows systems) as well as the targets for other testing frameworks on Linux may be provided with T2C tools in the future. Or they may be developed separately. If you would like to contribute to “Template–to–Code” project this way, feel free to do so. See Section 4, “T2C File Generation Targets” for the details on how the existing file generation targets are organized and what is necessary to prepare a new one.
Unless specifically stated, C language is used in the examples in this manual.