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 is this release are support for floating point validations and function mocking. Also, MinGW has been added to the list of supported platforms.
moreTestApe forum is now hosted on Proboards. Support questions can be posted here or send directly on email. Due to ...
moreTestApe can now be used with MinGW GCC on windows. Also supported in this beta are floating point types in validations or when mocking functions
moreA small fix for webtty scripts, to allow the usage from Apple IPads. Tab on textarea to bring up IPad keyboard - you may have to scroll webpage beneath keyboard, in order to actually see what you're typing.
This release contains a new flexible mocking system with default mocks automatically generated for unresolved functions. Installation packages are available for GCC/Linux, GCC/CygWin as well Visual Studio 2009/Windows XP or Vista.
moreNew 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. ...
more