This is the final piece of a three-part series on building reliable embedded systems.
- Off-Grid PAYG Solutions in Limited or No Connectivity Environment
- Reducing Risks in Embedded Software with Static Code Analysis
- Developing PAYG Embedded Software Modules with Unit Testing << You’re Here
In this three-part series we’ve previously explored how Angaza uses cost-benefit analysis and static code analysis to build reliable embedded systems. In the final piece of this series, we take a look at how Angaza develops unit tests to build confidence that its embedded (Pay-As-You-Go PAYG) application code performs as designed.
Embedded systems extend beyond software and marry real-world electrical and mechanical constraints. Some can include real-time interrupts to be serviced within microseconds, system architectures that must resist thermal or electrical failures, and changes to hardware design that require retesting system software. These unique constraints often isolate embedded software development from the larger software community. And while these constraints introduce additional testing compared to ‘software-only’ applications, thoughtful system design allows us to reuse many of the same testing techniques as less constrained applications. In fact, separation of concerns and designing for testability, among other standard software engineering principles, can be applied to embedded development. Among other tools, Angaza utilizes unit testing to build confidence in its application code.
Embedded systems code often involves low-level hardware operations, such as direct register accesses. In order to design effective unit tests in this environment, its important that our application code is decoupled from the hardware interface logic. By using a modern unit testing framework (“Ceedling”) and mocking the functions which interact with the underlying hardware, we’re able to ensure that our embedded application logic is unit tested just as rigorously as any other part of our solution.
While unit tests cannot replace system integration tests or the need to perform testing on the target hardware, they allow development of embedded software modules in parallel with and in isolation from the hardware. Although there is an upfront cost to writing unit tests, once written, they can be scripted to execute automatically every time the code in a project changes. This safety net ensures that future code changes do not break existing functionality, letting engineers spend more time solving new problems and less time manually testing existing logic.
Learn more about unit testing at Angaza, with real world examples and technical notes, in the original article.
Full Story: Reliable Bottom-of-Pyramid Embedded Systems: Automated Testing and Code Coverage
Published March 6, 2018 on Medium by Joshua Milburn.
