Any embedded program written in C for a device environment, can most likely also be
compiled for a PC environment. The TestApe unit tests are executed on a PC environment.
Eventhough the tests do not guarantee the behavior of the embedded code once it is
transferred to the device, they can still be a very valuable for the development
process by supporting test driven development and regression tests of the software
asset.
In classic software development, a modest complicated software program is typically
decomposed into several cooperating modules. The compiler interprets the source code
for each module and creates an object file holding the compiled code. The linker
assembles all the object files and creates the complete executable.
If one or more, of these modules were not present, the linker could not assemble the
software program and it would not be able to execute. In TestApe terminology, an incomplete
assembly of modules is called a unit. See also
Using the TestApe instrumenter
The individual modules in the unit, can be source files, object files or library files.
The amount of modules in the unit determines what functionallity that is tested.
As each module might be delivered at different times by diffrent groups of people, it is
possible for each group to define units that makes their code testable without relying on
the deliverables from other groups. Check out other
good reasons to do unit testing
The TestApe instrumenter combines the selected modules with the framework and the TestApe tests in order to turn it all into a TestApe executable. modules.
The TestApe tests
are engineered by the software developer to test this particular combination of
modules. For example test_code.c shown below, will test the unit
composed of the source files prg_a.c prg_b.c prg_e.c prg_g.c prg_i.c
void test_prg_a_init_failed(void)
{
// prg_a_init must first call prg_c_init.
// If the call is detected, then the framework
// will return INIT_OK from prg_c_init
SIMULATE(prg_c_init, INIT_OK);
// prg_a_init must then call prg_f_init.
// If the call is detected, then the framework
// will return INIT_FAIL from prg_f_init
SIMULATE(prg_f_init, INIT_FAIL);
// Nu further function calls are expected
// after this. If more are called, we found an
// error
// Now, stimulate prg_a, by calling prg_a_init
// and verify that a failing prg_f_init causes
// prg_a_init to return FALSE
VALIDATE(prg_a_init(), FALSE);
}
testape gcc test_code.c prg_a.c prg_b.c prg_e.c prg_g.c prg_i.c testape.a -o test
If you want to try it out yourself, you can find the download section here
New beta version is now available for download. This is the last beta before official release. The release supports an extensive mocking system.
moreThere is a change for the forum hosted on this site. The previous phpBB forum is closed for now. All forum threads will be migrated to a new simple blog. ...
moreA minor update has been released in order to support GCC when running in a CygWIN environment.
moreThe major update this year has been released. It includes a reference manual and macros to support test parameters and improved usage of the automatic stub instrumentation.
moreThe site has been updated. The webtty package has been tugged safely away in the corner and the TestApe ...
more