Name: spark-unit-test
Owner: Particle
Description: Running tests on the spark core.
Forked from: m-mcgowan/spark-unit-test
Created: 2016-02-25 13:32:10.0
Updated: 2016-02-25 13:32:12.0
Pushed: 2018-01-03 18:47:06.0
Homepage: null
Size: 18
Language: C++
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This is a port of the Arduino Unit library to the spark. Please see that repo for library usage, or check out the examples.
Additions in the spark version:
cmd(include=pattern)cmd function is called with 'start'These features are documented below.
When the test suite app executes, it initially enters the waiting state. The RGB led shows the usual breathing cyan as the spark is connected to the cloud.
When the test suite is later started, the RGB led shows a solid color to reflect the current test health:
When the test suite has completed running, the LED status remains so you can leave the spark running and come back when it's done to see the result. (In future, the LED may blink while the tests are running, and then return to solid when all tests are done, to make it easy to see when the tests are still running or not.)
Tests can be filtered at runtime using include/exclude globs. The include/exclude feature is described in the Arduino unit documentation.
To exclude tests ending “*_slow”:
k call mycore cmd exclude=*_slow
To run only tests starting with 'abc':
k call mycore cmd exclude=*
k call mycore cmd include=abc*
If the test code hasn't requested the test suite starts immediately, the test suite will wait until:
cmd(start) function is called.E.g. to start the tests via the cloud:
spark call mycore cmd start
As part of a locally operating automated tset suite, it can be useful to put the core in DFU mode for quick flashing of another app.
This is done with the command
spark call mycore cmd enterDFU
On receiving the command, the core will reset and enter DFU mode (flashing yellow LED.)
The test suite exposes variables to the cloud to allow monitoring of the test health:
These variables are updated as the test suite executes.
The test suite publishes events as the test runner state changes. This allows external apps to monitor progress, e.g. wait for the test suite to complete.
The event state is published whenever the running state of the test suite changes.
The event can have these values:
(NB: it would be easy in code to add an event each time a test has been executed, however this could easily generate too many events causing more important events, such as the running state change 'complete', to be dropped.)