-
Notifications
You must be signed in to change notification settings - Fork 99
Test Infrastructure
Tests rely heavily upon C++ inheritance and polymorphism to solve various requirements. The base class of every test is called Test, and attempts to place constraints and guidelines onto developers to support the following:
- Force developers to code test logic in a uniform way.
- Force developers to document tests, but alleviate the burden as much as reasonably possible.
- Allow many ways for a test to report errors.
- Bind and control resource lifetimes.
- Check for hidden PCI or controller space register errors.
The base class to every test has a pure virtual method called Test::RunCoreTest(). This method must be implemented within all children otherwise they cannot be instantiated. RunCoreTest() is where each and every test contains its core test logic. This is the effective entry point into each and every test residing within the framework.
The children derived from base class Test are required to document the reason for the existence of the test, as well as other useful information. All tests are documented in a similar manner and will have a common output displayed when a user requests test details from the command line.
Specifically, the children must supply valid and relevant text by populating member variable Test::mTestDesc within the constructor of the child. This member variable is itself an object and requires initialization of the following items:
- SetCompliance() - Which section and spec revision the test targets.
- SetShort() – Provide a short 66 character description for test cases existence.
- SetLong() – Provide an unlimited amount of text to thoroughly describe the test scenario.
This duty, albeit cumbersome but simple, will be vital to handing off test case descriptions to future generations.
There are basically two acceptable methods of reporting test case errors and/or compliance violations to the framework. Due to the fact Test::RunCoreTest() returns a bool, a developer must return false upon errors and true when the test successfully passes. The other mechanisms is to throw a std::exception() from anywhere within the child class. All exceptions are caught by the base class and are converted to the proper reporting mechanism to report to the framework. ?Users see a test case ending in error when one throws from within test case source code.
During usual test case execution the test may create an environment and decide on the pass fail criteria of the logic. The framework adds further test case pass fail criteria by looking at the PCI register space and detecting any PCI error bits which have been set during the test run. The same holds true for the controller register STS. All registers which are checked after each test executes, are reset before the test runs. This wrapping guarantees if a bit has become set, it is the result of what has occurred within the test. For complete details see method Test::GetStatusRegErrors().