While using the development version of platformio 2.0, I noticed a change in the way unit testing was implemented.
Correct If my understanding is skewed, we are using the platform = native declaration in the platformio.ini file to unit test the code locally using the systems gcc. The other defined environments help is conducting the target testing. Say, if we are using the arduino uno for a project, due to the differences in avr-gcc and native gcc, the tests cannot be written in the same fashion. Arduino expects the setup() and loop() functions and the native gcc expects and main() function. Hence we are seperating the tests into test_native and test_embedded and adding the test_ignore option in both environments in the platformio.ini.
This approach requires that the code architecture itself be independant on the underlying API for the arduino if we are testing it on the native platform. We are limited to testing only the program flow independant of the hardware. There is no way to unit test the hardware itself on the native platform.
I would like to request if we can integrate cmock into the test framework along with unity, so that the underlying arduino API itself can be mocked out and simulated even in the native unit testing. Presently, there is no way we can test if the code performs as expected when a hardware register or timer etc returns a out of bounds value or throws an errror.
I have a a preliminary look at it and it seems sound.
Is there an end to end example which demonstrates all its functions.
Hello, I have had a look at your mock lib for the unit testing in the link Ivan posted above. I was wondering if you could help me out in this regard. Do you have a end to end example or documentation that explains the whole usage pattern which will definitely be a big help to me and also helpothet who might have the same requirements.
The library I’ve linked to only makes use of the millis() function, although pinMode, digitalRead, digitalWrite, analogRead and analogWrite are already supported. Adding additional methods is fairly trivial (and any pull requets would be greatly received!)