Part 1 – Testing the calculations and internals
Testing software is a very important part of the development process and this can be broken down into two areas, firstly the internal calculations, database queries and procedures (Part 1) and secondly the User Interface (UI) making sure that the results and UI are working as designed (Part 2).
The FPAssistant suite SDK now has many thousands of tests covering the source code and these test cases with results can come from publications (ICAO/FAA/Eurocontrol), an algorithm in the test code, another software product, etc. It is important to stress that the FPAssistant SDK DLL is not shipped unless all test cases are passed.
Microsoft Visual Studio Test Explorer
Above is a screen shot showing the test explorer that the development team use to see the test structure with the ability to execute a single, multiple or complete test run. Test cases can be very quick to execute and in this case 11 milliseconds (ms). The image shows that the test case data has come from ICAO Document 9906 relating to TAS values and below is another image showing the test data in the ICAO document.
ICAO 9906 App D – TAS Calculation Results
From the table above the input values of IAS, Altitude and ISA are entered into the test code along with the expected calculated value; the TAS.
Test Source Code (C#)
Testing is easy as we can test directly from the source code rather than using the “Test Explorer”, these are the two small green filled circles with a white tick; if the test had failed or is failing then we get a red circle with a white ‘x’.
When developing new API’s to the FPAssistant SDK we try to add as many test cases as we can and it’s often that more man-hours are expended finding, developing and writing the test cases that writing the code to perform the requirement!
Also, we try to write test cases that cover all of the source code that is developed and this come under a term called Code Coverage; I have written a previous blog on this topic here. Having a high percentage of source code covered by test cases means that any changes or refactoring to the source code can easily and quickly tested to see if there are implication elsewhere in the product.
Our partners that work with us often contribute to test cases and this allows us to keep a high set of test cases.
In Part 2 I will describe how we test user interfaces in our test app which is an automated process that saves a person having to sit at a computer testing the software.
