20,741
edits
Software testing: Difference between revisions
Jump to navigation
Jump to search
m
For future reference →Nasal testing: https://sourceforge.net/p/flightgear/mailman/message/36991401/
(→SimGear: Some initial text.) |
m (For future reference →Nasal testing: https://sourceforge.net/p/flightgear/mailman/message/36991401/) |
||
| Line 83: | Line 83: | ||
and git skills required for implementing your test on your fork's new | and git skills required for implementing your test on your fork's new | ||
development branch :) | development branch :) | ||
=== Nasal scripting (comments) === | |||
{{WIP}} | |||
The now builtin CppUnit framework can obviously solve all the issues | |||
identified in the old [[Nasal Unit Testing Framework]] wiki article and the discussions it points to | |||
and provide the full framework required.<ref>https://sourceforge.net/p/flightgear/mailman/message/36990615/</ref> | |||
we have route-manager tests which validate route_manager.nas is working correctly, and we have Canavs tests which poke the Nasal API. <ref>https://sourceforge.net/p/flightgear/mailman/message/36991200/</ref> | |||
We need more FGData testing via the test suite. | |||
Adding the CppUnit assertions to Nasal, is the task James has been suggesting he would do, so others can write tests in pure Nasal. | |||
The other piece is some C++ code to scan a directory for files matching a pattern, eg test_XYZ.nas, and to run each of those automatically.<ref></ref> | |||
The idea for testing Nasal would be that you write a small CppUnit | |||
interface in c++ in $FG_SRC/test_suite/*_tests/ (the FGData Nasal | |||
testing would be in a fgdata_tests/ directory). This would register | |||
each test which points to the script in | |||
$FG_SRC/test_suite/shared_data/nasal/, and the setUp() and tearDown() | |||
functions would use helper functions in the fgtest namespace to start | |||
and stop Nasal. The Nasal scripts could then call the CppUnit | |||
assertion macros wrapped up as Nasal functions for communicating | |||
failures and errors to the test suite. <ref>https://sourceforge.net/p/flightgear/mailman/message/36991150/</ref> | |||
Scanning for scripts is a great idea. Then developers (core and content) could write tests in pure Nasal. | |||
However all scripts found and executed will be seen as a single test within the test suite. So maybe we should have a $FG_SRC/test_suite/nasal_staging/ directory for initial development of such auto-scanned scripts. But then we have someone shift them into $FG_SRC/test_suite/system_tests/, $FG_SRC/test_suite/unit_tests/, or $FG_SRC/test_suite/fgdata_tests/ later on? That would give better diagnostics and would avoid long-term clutter.<ref>https://sourceforge.net/p/flightgear/mailman/message/36991198/</ref> | |||
* First we should probably hard code tests into the C++ framework. The CppUnit assertion macros will have to be wrapped up as Nasal functions for this. | |||
* Then implement the scanning code as we need some CMake magic (probably using file(COPY, ...)). | |||
* Finally work out if and how we need to improve the Nasal debugging output. | |||
the code could go into a subdirectory in $FG_SRC/test_suite/fgdata_tests/, and the Nasal script in $FG_SRC/test_suite/shared_data/nasal/. | |||
== References == | == References == | ||