First International Test-Driven Development Conference

Last 10th of July I presented for the first time my talk named 'Unembedding embedded systems with TDD. Benefits of going beyond the Make It Work phase' as part of the First International Test-Driven Development Conference.


Test-Driven Development (TDD) is a development technique that facilitates software developers to face the 'Make It Right' development phase safely just after they've successfully completed the 'Make It Work' phase (that is, we have already gone from 'Red' to 'Green' TDD phases).

Once we are on the 'Make It Right' (TDD's 'Refactor' phase) is when we are able to focus all our energy on engineer our code right, iteratively, to properly manage its dependencies. In other words, is when we drive our code to have the appropriate architecture to be portable, easy to change and evolve.

Here you can see an schematic representation of the architectural layers we end up to have in order to accomplish the above mentioned objectives:


To accomplish that we need to use, among other things, advanced programming language features. Doing this in embedded is orders of magnitude harder than in non embedded. TDD allows us to drive our code through them, step by step, while assuring both the cross compiler and the underlying processor keep working as expected (i.e., we do not enter undesirably into the 'Red' phase).

  1. Do you know how to apply TDD in order to develop your code unchained from undesirable dependencies? 

  2. Have you noticed that some code dependencies have weight dimension [Kg] (for example, the hardware) and others have only data dimension [Kbyte] (for example, a third party software library)? 

Has the coupling degree between your code and its dependencies a direct relationship with dependencies' weight dimensions?

If you are not an embedded developer, do you think you write some kind of firmware?. Spoiler: probably you do 😉 

If you are an embedded developer, are you aware that, in order to succeed, your embedded application and its business logic should be able to be executed under any hardware and by any microprocessor? 

Are you agile enough to overcome a hardware or processor change, for example, due to a chip shortage or other internal requirements? 

Are your vendors also your partners? 

Is code coverage an useless or a harmful metric?. Do you know what mutation testing technique is? 

Is your business viability assured if you are fulfilling your sector's safety critical standard? 

Are Extreme Programming (XP) practices used inside the embedded crown jewel, that is, safety critical systems sectors? 

Are our code errors and their related bugs somehow critical even when we're not working on a safety critical sector? 

Is TDD a testing technique which benefits can be compared with any other test-later approach? 

You can find answers to these and other interesting questions on the talk. Major roadblocks to overcome and how to remove them are presented. Somehow, it represents a kind of resume of all the topics covered during my 'Unembedding Embedded Systems' course.

Below you have a direct link to the talk and you can find its slides here.