Setting up PlatformIO for CI/CD with Testing, Code Coverage and Versioning

Announcements
, ,
1

Today almost all professional software development is executed using an agile methodology with version control, automatic testing and builds in the cloud. However, this is not yet very common for firmware development.

This article explores how to set up a PlatformIO project and benefit from all the CI/CD features of modern software development approaches.

3 Likes
4

Thanks for putting putting the blog & demo repo together.

It has been expressed by others before on this forum & hardly comes as a surprise, but I’ve found unit testing on embedded projects difficult & time consuming due to inter-dependencies & reliance on hardware interaction.

What I think may solve the issue (& would be an extension of this blog) is automated testing on hardware, as detailed here. I haven’t tried this solution yet but it seems appealing. Unfortunately its not an open-source solution, but might be useful for others.

PS. I’ve no affiliation with the company providing this service.

5

Hi, thanks for this suggestion, it’s certainly worthwhile to explore.

Know that PlatformIO already has a similar setup possible with ‘remote testing’ pio remote test — PlatformIO v6.1 documentation

As for the difficulty to unit test hardware related stuff : I agree, but once you have the ‘test-driven-design’ mindset, you will find that it is possible to organize your code so >90% can be hardware independent and thus unit tested easily.

One example (from a design I am currently working on) : a display driver for an epaper display. At the lowest level there is an SPI (+ some extra signals) and this is off course HW dependant. But by having a displaybuffer in RAM, it’s only the SPI copy of this displaybuffer to the display hardware which needs to be tested on the HW itself. Everything ‘above’ that (all pixel manipulation) is generic and does not need HW.

Same for eg I2C interfaced sensors : you can easily mock them by having the I2C data transfer redirected to a memory mapped copy of all the sensor’s registers.

6

I’ve shared a link (and my thoughts after reading an article) in Fediverse: Alexey Vazhnov: "An article about #embedded code testing, automati…" - Mastodon

7

Hey Alexey, thanks for your remarks.

  • it’s using github actions as this is the version control environment that I have chosen.
  • running the (generic) unit tests on the hardware is easy to add, with an additional PIO environment ‘some target unittests’
  • using hardware simulation/emulation was not included as this would make the already long blog post too long to digest. Maybe I can do that in a future article.

Pascal

1 Like
8

@strooom , thank you for the article and for your answers!

I just want to make it clear: my notes/thoughts are not to criticize, but to adjust expectations of a person, who decided to follow the link.

1 Like