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.

  • 1
    Of course it’s possible. But the tools are different. Be warned that the syntax for function pointers is wacky. Commented Apr 20, 2020 at 22:06
  • 4
    Having knowledge of the platform you are targeting is always a boon - regardless of it being embedded or not.
    – Kain0_0
    Commented Apr 21, 2020 at 1:39
  • 2
    You need to have enough knowledge to understand what you are testing and why. This doesn't mean you need to have years of experience in embedded systems--you can learn as you go.
    – Dan Wilson
    Commented Apr 21, 2020 at 1:59
  • 2
    Come on, do you really expect strangers from the internet, who don't know you in person, tell you what kind of learner you are and if / how quickly you can learn this new field?
    – Doc Brown
    Commented Apr 21, 2020 at 5:46
  • 1
    You could check out the book "Test Driven Development for embedded C" which gives an excellent treatment of the techniques involved, it's a great place to start and imo quite readable even for a non-C programmer. Commented Apr 21, 2020 at 9:40

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.