Is it possible to write unit tests for embedded systems with no prior embedded programming knowledge?

Question

I have this question for a long time that is it possible for someone with no prior embedded systems programming experience to write unit tests? I have good knowledge of other languages like JAVA, Python, C# and a few others. I can write unit tests in the mentioned languages. But I have never done any project in C or C++ and have basic knowledge about embedded systems.

I want to know how challenging this can be and what are the possible issues I can face while moving from general business software development to embedded systems?

I know that with time one can learn any field. I want to know the experiences of those who have worked in both areas and tell me about the challenges they faced so that one can be better prepared.

Answer 1

I had been programming embedded systems for a while. I think the key thing you need to write good unit tests for embedded systems is that you need to have a clean interface for accessing hardware.

If your code accesses hardware everywhere, it is tightly-coupled and untestable. So it is related to software design knowledge rather than embedded programming knowledge.

Treat hardware as the external dependencies that are not always available, like some 3rd party web APIs. You don't want to connect hardware to run unit tests, although you need all dependencies for integration tests.

If you have a clean separation between code of accessing hardware and software logic, you can apply mocking/stubbing to write and run unit tests without hardware presence. Then you need may unit testing frameworks, but that should be less related to embedded programming.

---

My background is the opposite of you, I moved from embedding programming to general business software. The main challenge of writing unit tests of embedded systems is about the clean separation between hardware and software that I mentioned.

Comparatively speaking, changes to the code related to hardware is less frequent than usual software. Because the cost of testing and debugging is higher when involving hardware, it may involve manual procedures that cannot be automated.

Therefore, if the code is tightly coupled in the beginning, it tends to remains untestable, because the effort of refactoring to make it testable is high.

So my advice would be: make the code loosely coupled in the first place and spend more time in the design phase.

Answer 2

Writing good (useful, readable, orthogonal and concise) unit tests is pretty much the hardest thing you can do in any domain, in my experience. But you should only need to know the language, its paradigm, and the surrounding tooling to do it. Understanding the runtime platform is generally not required unless you're writing acceptance tests.