This page is developer info about a proposed framework to automatically test GenBoard computer and config over millions of cycles There is a need for more formal testing of the firmware.

Automated as much as possible, and perferrably unit tests to ensure all is well with each revision/compile of the code. This is often called automated regression test. Why do we need this if it already "works"? Tests can be written to ensure corner cases are handled properly, and that changes in one area don't affect another unexpectedly.



I can allocate

I can allocate more genboard, but I'd be happier if 2 is enough.

The task of the participants:

Parameters to measure:

For now:

Maybe at the same time (through primary and secondary trigger). Optionally only one of those at a time.

Simulated Regression Testing

A good way is some kind of simulator / vitural machine (another way is if one board tests the other, what we also do). Ideally it could run at a C source level to facilicate debugging, but I've been unable to find anything quite that advanced so far... Fredrik's work on OnlineCourse/PcEmulation will come useful, for sure.


It's an assembler level analyzer, simulator, debugger. What's interesting is that it has testing facilities, and the lead developer is keen to get that functionality finalized. It means we can build a basic model of the Genboard I/O in Java, and run a JUnit-ish test suite over the firmware.

With the release of Avrora 1.40 Beta, we have a means of black-box unit-testing the firmware. It has a gdb interface now, so it might be useful for debugging too if we're lucky.


Some other simulators are:

Please feel free to contribute so we can realise this.

There are several ways we can attack the testing problem:

Code review of every line written - necessary, but not enough in itself

Every commited line is read by atleast one other developer.



Unit-testing - helps to avoid the tedious manual testing task after refactorizations

Either standard unit-testing, or use of [Design by Contract].



Systemwide testing

Testing the entire system by running through a set of scripted tests. A simple example may be 'send in this waveform, expect these RPMs'. More advanced tests would simulate an entire chain of events that happens at roughly the same time.

Could be ran both against the



I'm almost certain we need this. Almost the same as we do with alien ECM-s (log alien advance and fuel pulsewidths).