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.
- specifies the directory that will hold the harness packages and project file
for the test driver. The harness directory should be specified either by that
switch or by the corresponding attribute in the project file.
- 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 gnatstub 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 either in the harness-dir as specified on
the command line or in the 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
Note that you might need to specify the necessary values of scenario variables
when you are not using the AUnit defaults.
- actual unit test stubs:
a test stub 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
"tests" directory that is created in the directory containing the source file
itself. If it is not appropriate to create the tests in subdirectories of the
source, option --separate-root can be used. 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-tests-proc_<code>.adb. <code> is a signature encoding used to
differentiate test names in case of overloading.
Note that if the project already has both my_unit.ads and my_unit-tests.ads,
this will cause a name conflict with the generated test package.