Our firmware team develops embedded software for Automated Teller Machines written in C. Our team was first introduced to Test Driven Development in May 2014 when James came to our office for his one week TDD course. The concepts were very strange and foreign and quite often he suggested we should do things exactly opposite as we were. Towards the end of the course though, it began to click. As soon as we got back to work after the training, our code started to get better – slowly but surely. Most of our existing code wasn't testable in its original state. But with the new knowledge of what testable code looks like, we started making incremental improvements towards testability while doing bug fixes and adding small features. Eventually we started adding new features to legacy code (code without tests) using TDD.

Seeing the value in having code under test, we began reworking the most important legacy modules to get them under test. In doing so, we started to see our legacy code in a very different light. The biggest surprise was the amount of duplicated functionality (that had existed for years). It became obvious when the tests for unrelated modules were eerily similar. Not wanting to waste time writing duplicate tests, objects were born. These objects (a notification queue for example) were written once using TDD but used by many other modules. In the first few months, we removed thousands of lines of production code while keeping the same (or better) functionally and the code became modular, easier to read and maintain and of course, testable.

We’ve been practicing TDD for a few years now and have reached the point where all new code is developed using TDD. Our code is continuously improving but at the same time, the team’s approach to software development is improving too. We now do daily stand up meetings, pair programing, code reviews and are continually honing coding best practices specific to our team. Another interesting side effect is the new found freedom to effectively develop embedded software away from our desks (and hardware); in a meeting room, at home or on the road. We recently replaced our desktop development PCs with laptops and we even tore down our cubicle walls to improve communication between developers.

TDD has not been without it's learning curve. It simply takes experience to write good tests and know what can and can't be tested with TDD. We've had some ups and downs but are fully committed to TDD. We can respond faster and more confidently to bug fixes and requirements changes. We have shown that fewer defects reach our test lab reducing the number of manual test iterations and ultimately, fewer defects reach our customers.

James was very helpful during our training and continues to be long after. I highly recommend his training for anyone looking to improve their embedded software.

Ben

PS Our next step in continuous improvement is a continuous integration build sever.