Unit Test GUI: A graphical interface for testing in python
The unittestgui is a graphical interface for code written using the unittest class that is a part of the standard python library. The code has been written in python and makes use of the wtl_package; the python interface to the DigitalFMux boards. To make use of the test suite, the following will be needed:
Requirements
- Appropriate version of unittestgui compatible with the Python interpreter that is installed on the system.
- Test suite; the folder containing the testing code.
- Modules; the python modules used to interact with the boards. It is advisable that the modules folder should be placed in the same directory as the test suite folder. If it is somewhere else then notify the software by opening up the WinterlandTestCase.py file in the test suite directory and in line no. 2 , alter the append command accordingly.
Information you need
Before getting started, information about the testing environment needs to be given to the code. The information needed is as follows:
- IP address of the board
- IP address of the computer being used for testing.
- Variances of noise and output (streamed at1Mhz and 1 amplitude for the modulated signal and 0.999995Mhz for the demodulating signal). These variances should be calculated by streaming data samples manually. The noise variance can be calculated by using samples from an expected zero output. By default, if the standard demod dongle model is being used, noise variance should be set to 1 and output variance should be set to 300.
- The range of housekeeping values that depict normal operating conditions of the board. These values include motherboard currents and voltages and temperature sensor values.
All this information should be fed to the wtl_tests.ini file contained in the testsuite folder. Also mention which mezzanines are connected to the board, or in other words which mezzanines do you want to test.
Running the Tests
While keeping the test suite folder as your current directory, type in
python unittestgui.py
. This should open up the unittestgui.
- Type in the name of the test that needs to be performed, for instance "DfmuxTests", and hit return. The python code is case sensitive so make sure you enter the exact same name.
- The tests contained in each of the files will be run one by one until they complete successfully or a malfunction causes them to crash.
- These tests can take a few minutes and while they are running the unittestgui appears to have crashed. Give it time, it will only perfectly respond once the tests are complete.
- Double clicking on the tests that failed lets you look at some more information about the failure.
- The test log is by default added to
/tmp/myapp.log
. The filename or path can be changed in the WinterlandTestCase.py file.
A brief introduction of the tests
The following is a brief overview of the test files located in the test suite folder.
- DataStreamerTests.py : To run this file just type "DataStreamerTests" into the unittestgui. The class contains three tests. It tests for an operational launch, kill and data transmission of the data streaming process on board. Please note that it only checks for a successful transmission of data and not for the content of the data.
- DfmuxTests.py : This class checks for an operational Dfmux through three tests.
-
- testRegisterReadback() : This test configures the registers responsible for holding the dfmux settings like frequency, amplitude and phase for the carriers, nullers and demods of all the channels. It configures each channel on each wire, checks every time if it has been properly configured and ensures that other channels on the same wire have not been disturbed by the current configuration. It should be noted that the test only checks register values, and not the values at which the Dfmux might actually be operating.
-
- testDmfsChannelSeperation() : This test takes the previous test even further by checking if the values stored in the registers are getting through to the dmfs or not. The only way to do that is to check the output at the dmfd. So the test intelligently configures all the channels on a particular wire, setting the values such that the output should be zero. If the values are getting mixed up by the registers or by the process that takes the values from the registers to the dmfs, the output would come out to be non-zero. This test takes into account a maximum background noise level, and ensures that the output at the dmfd is zero. At one instance of the test, the values of the registers are as follows in one wire
Dfmux Settings |
| Carrier | Demod |
Channel | Freqeuncy | Amplitude | Frequency |
1 | 1000000 | 0 | 999995 |
2 | 0 | 1 | 0 |
3 | 0 | 1 | 0 |
4 | 0 | 1 | 0 |
5 | 0 | 1 | 0 |
6 | 0 | 1 | 0 |
7 | 0 | 1 | 0 |
8 | 0 | 1 | 0 |
-
- testOutput() : This test basically checks the synthesis of a required sine wave at the dmfs by checking its demodulated output at the dmfd. The test is performed by calculating the variance of data samples received at the dmfd and by ensuring its over a certain value. I calculated the minimum variance using one board. In case the tests fail, the value might need to be revised using more then just one board for the tests to work correctly. The values for every channel are set as follows:
| Carrier or Nuller | Demod |
Channel | Frequency | Amplitude | Frequency |
1 | 1000000 | 1 | 999995 |
- FpgaMotherboardTests.py : At the moment contains only one test which ensures that the housekeeping values lie in between the given ranges specified in the wtl_tests.ini file.
- MezzanineTests.py : Also contains only one test for now which checks the housekeeping values for the mezzanines.
- SquidControlTests.py : Contains two simple tests. The first one checks whether the squidcontrol board is connected to the main board properly or not by trying to power it on. The second test which is a bit more detailed, tries to configure all the different settings on each channel and tries to read them back in order to ensure that they have been properly configured.
This topic: Main
> TWikiUsers >
ShahWarraich > TestDocumentation
Topic revision: r5 - 2008-06-05 - ShahWarraich