26.1 Running gnattest

gnattest has a command-line interface of the form

     
     
     $ gnattest -Pprojname [–harness-dir=dirname] [switches] [filename] [-cargs gcc_switches]

where

-Pprojname

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.

filename

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 path.

‘gcc_switches’

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.

switches

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:

            gnatmake -P<harness-dir>/test_driver
            test_runner
  

  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 overloading.

  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.