Creation of test skeletons for primitive operations of tagged types entails a number of features. Test routines for all primitives of a given tagged type are placed in a separate child package named according to the tagged type. For example, if you have tagged type T in package P, all tests for primitives of T will be in P.T_Test_Data.T_Tests.
Consider running gnattest on the second example (note: actual tests for this example already exist, so there's no need to worry if the tool reports that no new stubs were generated):
cd <install_prefix>/share/examples/gnattest/tagged_rec
gnattest --harness-dir=driver -Ptagged_rec.gpr
Taking a closer look at the test type declared in the test package Speed1.Controller_Test_Data is necessary. It is declared in:
<install_prefix>/share/examples/gnattest/tagged_rec/obj/gnattest/tests
Test types are direct or indirect descendants of AUnit.Test_Fixtures.Test_Fixture type. In the case of nonprimitive tested subprograms, the user doesn't need to be concerned with them. However, when generating test packages for primitive operations, there are some things the user needs to know.
Type Test_Controller has components that allow assignment of various derivations of type Controller. And if you look at the specification of package Speed2.Auto_Controller, you will see that Test_Auto_Controller actually derives from Test_Controller rather than AUnit type Test_Fixture. Thus, test types mirror the hierarchy of tested types.
The Set_Up procedure of Test_Data package corresponding to a test package of primitive operations of type T assigns to Fixture a reference to an object of that exact type T. Notice, however, that if the tagged type has discriminants, the Set_Up only has a commented template for setting up the fixture, since filling the discriminant with actual value is up to the user.
The knowledge of the structure of test types allows additional testing without additional effort. Those possibilities are described below.