26.1 Running gnattest
gnattest has a command-line interface of the form
$ gnattest -Pprojname [–harness-dir=dirname] [switches] [filename] [-cargs gcc_switches]
- specifies the project defining the location of source files. When no
file names are provided on the command line, all sources in the project
are used as input. This switch is required.
- is the name of the source file containing the library unit package declaration
for which a test package will be created. The file name may be given with a
- is a list of switches for
gcc. These switches will be passed on to all compiler invocations
made by gnattest to generate a set of ASIS trees. Here you can provide
-I switches to form the source search path,
use the -gnatec switch to set the configuration file,
use the -gnat05 switch if sources should be compiled in
Ada 2005 mode, etc.
- is an optional sequence of switches as described in the next section.
gnattest results can be found in two different places.
- automatic harness:
the harness code, which is located by default in "gnattest/harness" directory
that is created in the object directory of corresponding project file. All of
this code is generated completely automatically and can be destroyed and
regenerated at will. It is not recommended to modify this code manually, since
it could easily be overridden by mistake. The entry point in the harness code is
the project file named test_driver.gpr. Tests can be compiled and run
using a command such as:
Note that you might need to specify the necessary values of scenario variables
when you are not using the AUnit defaults.
- actual unit test skeletons:
a test skeleton for each visible subprogram is created in a separate file, if it
doesn't exist already. By default, those separate test files are located in a
"gnattest/tests" directory that is created in the object directory of
corresponding project file. For example, if a source file my_unit.ads in
directory src contains a visible subprogram Proc, then the corresponding unit
test will be found in file src/tests/my_unit-test_data-tests-proc_<code>.adb.
<code> is a signature encoding used to differentiate test names in case of
Note that if the project already has both my_unit.ads and my_unit-test_data.ads,
this will cause a name conflict with the generated test package.