How to implement a test in the Test Supervisor

These are generic guidelines to help the implementation of a test in the Test Supervisor software

Make a plan

In first place one must define the several stages of the test and the procedures taken at each step. This plan should be divided by stages and by boards/applications. For example for testing the DCC's input handlers one can make the following plan (in chronological order of actions to be taken):

Stage Board Application Procedure Expected result
Configure DCC DCCTestSupervisor - get the board bags
- application ready for test action
Configure DCC DCC driver - send stop (1)
- configure board (2)
- send clear
- verify if iFIFOs are empty
- empty iFIFOs
- DCC in IDLE state
Configure DCC-TC xdaqDCCTester -send stop (1)
- configure board
-load memories with one event(3)
- store in a file the patters loaded per channel(4)
-send getready
- send start
- board configured
- memories loaded
-board in TRIGGER state
Test DCC-TC xdaqDCCTester -send start
-send step
-send stop
-board in IDLE state
Test DCC DCCTestSupervisor -submit TestJob -test job under execution
Test DCC DCC driver -dump the iFIFO contents to a file(4)
-send resynch
-verify if iFIFOs are empty
-empty iFIFOs
-DCC in IDLE state

(1) verify the status after each command (2) check configuraton (3) check memories contents (4) the file location is retrieved to the Test Supervisor when the configuration ends

Implement the test procedures in the drivers

For a new test the devices' supervisors application's will only take care of handling the result of the test returned by the drivers and there should not be, in principle, much changes, in case a new test needs to be implemented. So, the second step to take is to implement the procedures described in the previous plan in the board drivers. This may change from driver to driver. For example the DCC driver has a pointer to a handler for test requests. This handler class takes care of configuring for and executing the tests provided he receives the correct board bag, the test name and a string to log it's procedure. Has it's implemented within the driver this handler can access easily to all the driver's functionalities and control directly one board. Like this the device supervisor (in this case the DCCTestSupervisor) delegates to each one of the driver's it manages the execution of the hardware tasks, taking care only of the handling of the results. The delegation of tasks is defined in the ECALBase as a submission of TestJobs to workloops.

Define the test table and the board's configuration files needed for the test

Having implemented the test procedures in the drivers (which is the half of the way done in the coding work) one must then define:
  • the test table of this test that is stored in the ${TESTSUPERVISOR}/xml/TestTables/ directory. All test tables take the name of the test they define. In our example this would be DCCInputHandlerTest.xml
  • the configuration files needed for the board's configuration which are stored in the ${TESTSUPERVISOR}/xml/board_type/ directories. The configuration files take also the name of the test. In this case we have defined two configuration tables (one for DCC and one for DCC-TC) both named DCCInputHandlerTest.xml (and stored in the directories ${TESTSUPERVISOR}/xml/dcc/ and ${TESTSUPERVISOR}/xml/dccTester/ correspondingly).
The creation of these files resumes to copy and paste smile the existing files changing the parameters (or adding if necessary) according to the test requirements. Below you can take a look the configuration file for the DCC and the test table for the DCC Input Handler Test.

Prepare the Test Supervisor for the analysis stage

This is the second half of the way in what concerns the coding part...

Prepare the command to send to the Test Supervisor

This is the final step and for the moment we use the IntegrationTestsCommander application to take care of the command building and sending to the xdaq Test Supervisor application. The procedure can be summarized as follows:

  • GUI interface (implemented in )
    • check if all the widgets necessary for the user to define the basic test parameters are already implemented both in the Configuration tab and in the StandAloneTests and IntegrationTests tabs. The methods that implement the tabs take the name of the tab (p.e. StandAloneTests tab is implemented in the TestSupervisorGUI::BuildIntegrationTestsTab() method. The code's for the widgets are defined in the class TestSupervisorGUICodes.hh
    • verify what's the action taken when the start test button is pressed (i.e. check the TestSupervisorGUI::processButtonEvent() ) method. This will determine if the IntegrationTestsCommander will start an integration or a stand-alone test.
  • IntegrationTestsCommander interface (implemented in
    • verify if the SOAP message to be sent to the xdaq Test Supervisor application is well constructed namely: the name of the test, configuration mode and board bags to be written. In particular one must check if the configuration parameters needed to include in the board's bags are being correctly retrieved from the GUI. This is done in the methods IntegrationTests::addToTestActionBag()

So... that's it! Now you are ready to... debug what you coded. And then test.

-- PedroSilva - 22 Aug 2006

Topic attachments
I Attachment History Action Size Date Who Comment
XMLxml TestTables-DCCInputHandlerTest.xml r1 manage 4.0 K 2006-08-25 - 16:36 PedroSilva Test table for the DCC Input Handler test
XMLxml dcc-DCCInputHandlerTest.xml r1 manage 9.2 K 2006-08-25 - 16:36 PedroSilva Configuration file for the DCC board
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2006-09-05 - PedroSilva
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback