Proposal type: Hardware [ ] , Software [ ] , Other [ ] : _________________
Mostly software, but possibly might need additional testing server like the autotest or coverity server once implemented. Python has some excellent unittest libraries, and since we use waf for building( which is python ), it would probably be best that the unit test system be python based. Many unit-tests themselves will be compiled code, so they will clearly be C/C++, but the wrapper-tools around this will be python.
Description:Problem: The autotest server currently tests the âwell wornâ code paths that are used for flying an aircraft, and does an excellent job of that, but the âcorner casesâ and other code paths are unfortunately not tested so well. Solution: The unit tests proposal aims to fix this by building up a library of code path tests that should âalways workâ, but arenât validated well. Initially we can test that individual libraries give their expected output/s when given expected inputs, and/or we can choose to test higher-level functionality if desired.
Details / Plan for implementation: Itâs hoped that we will be able to implement a new Unit Testing âsystemâ, and integrate a fixed number of tests ( say 20?) of varying complexity that give a representation of what is possible with the system, and create a base on which others can build additional tests.
Planned amount: estimated $2000
Completion metrics:
a general unit-testing framework
ability to automatically execute the test suite.
10 new unit tests covering 2 subsystems ( probably based on existing âexampleâ code that some libraries have being made to execute in a repeatable / testable method ) - integration of at least 5 existing unit tests (such as in AP_Math/tests)
enough developer documentation that other developers can extend the framework easily.
more tests is definitely part of the proposal, but also increasing developer exposure to the testing, and hopefully having the ability to run these test automatically ( either as part of the standard build, or otherwise ).
We already run the tests for generic Linux board in Travis/Semaphore and anyone can run them with waf. We need to improve/add support for other boards though.
Our flight code is C++, so I think it makes sense to use unit testing for that.
I like this proposal, but Iâd note that we really need to also use gcov (or equivalent) to get us test coverage information, so we know which parts of the code arenât yet covered by tests. I think we could extend our current autotest.ardupilot.org output to include coverage graphs
Thanks for the comment/s Tridge.
Despite this being opened in Oct '16, I still think this Proposal holds merit. Yes, itâs about improving the coverage of code being validated/tested/executed across the entire stack, especially where individual libraries donât have their own unit tests, and/or where the high-level autotest suite doesnât cover it already, or only cover/s one path.
I donât know what I need to do to take this proposal to the next levelâŚ? Please funding committee, can u approve it.?
We are actively looking at ALL outstanding proposals, and getting advice from whoever might be the appropriate member on the specific topic.
It is our intention to have every existing proposal with a clear answer as soon as possible, so that every new incoming proposal gets answered within a very short timeframe, as stated on the new charter for the funding committee.