Open jlebar opened 4 years ago
martukas
commented
4 years ago Sounds good. We definitely need this as well. If we had something like this, we could definitely add it to CI and already make use of the networked pizzas for this. We have a Jenkins server up and running already.
martukas
commented
4 years ago Tulasi is getting in touch with ST to see if they can provide help with this.
asmodai27
commented
3 years ago There appears to be way to make this work for stm32: https://docs.platformio.org/en/latest/tutorials/ststm32/stm32cube_debugging_unit_testing.html#writing-unit-tests
Currently we can only run unit tests on host (i.e. your laptop). In
pio test run -e native, "native" means, the machine which compiled the code.We need the capability to run unit tests on the device as well.
Ideally we'd be able to run most or all of our unit tests on the device. But as a start, it would be helpful to have the capability of running some unit tests on device.
For example, we ought to have a unit test that checks that our clock only ever counts up. Obviously this test is only useful it it can run on the device itself. But because we can't run unit tests on device, I had to do it manually in https://github.com/RespiraWorks/VentilatorSoftware/pull/465#discussion_r437212802. We therefore have no regression check for this.
Some things this bug is not about
This bug isn't about what @martukas has been calling "integration tests" in https://github.com/RespiraWorks/VentilatorSoftware/issues/390 and https://github.com/RespiraWorks/VentilatorSoftware/issues/426. In these tests, he's configuring the device to take some action and then verifying physically externally to the device that it behaves as expected. For example, he may set a pin to a certain PWM and then verify using a LabJack that the pin has the expected duty cycle.
This bug is not about running on-device unit tests as part of continuous integration (i.e. CircleCI). That's worthwhile but complicated.
This bug is not about running on-device unit tests in emulation (e.g. qemu). Again, possibly worthwhile, but orthogonal.
Code pointers
If you try to run tests on device (
pio test -e stm32), you get a helpful error messageI think we need to write a test transport that uses the HAL debug serial API, defined in hal.h and debug.h. Seems somewhat straightforward.
The test itself unfortunately cannot be written using gunit, because there's no way (afaict) to redirect gunit's stdout to our custom test transport. The Unity framework should work.
(There was a period of time during which I thought we were going to need gmock, so I converted our tests to gunit. Turns out we don't need gmock, so it would be OK to slowly back.)