In 2012 I attended a one week course on TDD for embedded software developers given by James. The course was career changing for me, what I learned made more of a difference to my productivity than any other training I've had in my career.

I've always believed in writing software to test software, I've done this my whole career. Initially I wrote bespoke test applications. Then with the advent of test frameworks I started to develop UnitTests, and automate them within CI systems. I already felt that I was highly productive and generated good quality code.

So given that experience why did I find this training so helpful?

I think that I found the course easy to learn from because it was so interactive. This was far from death by powerpoint! James made great use of [Cyber-Dojo][http://cyber-dojo.org] as an online environment for us to work through examples. While we were coding James was able to monitor the whole class and gradually improve our TDD practice. There were lots of good real world examples to back up the theory as well.

What did I actually Learn?

• Testing first means that you can see how your test behaves when it fails - you know the test is good.
• Testing first influences design in a positive way. It helps to encourage good techniques like dependency injection.
• I learnt not to be scared of testing influencing design. I had always been wary of the concept of emergent design (I still am). I now work by developing enough design up front, and then using TDD for the details. When I find I can't test it tends to be a clue that the design needs some work.
• Refactor tests. The process James teaches requires you to think, to refactor your tests. As I mastered the process I have found that my tests have become smaller and smaller, testing just one thing. Repeated code is refactored and the tests can become a good specification for the code.
• How to get started with TDD in legacy code
• Tools and techniques that helped remove barriers to testing embedded software.

The course gave me the beginnings, enough to make me realise that I could do better. The second half of the week included time getting us started with our own code base. Since then practice has made perfect (well at least a lot better - I like to think I can always get better)..

What was the actual impact

I really got to reap the benefits of the training on my next project. Many of the team hadn't been on James' course. I was able to mandate unit testing and CI on the project, and I strongly encouraged and coached TDD. The project was in a new area for our business, was extremely challenging and had very tight timescales. Yet we delivered on time. I put a large part of this down to the number and quality of the unit tests that we had in place, both heavily influenced by the TDD training. When something was broken it was amazing how often a failing test directed us immediately to the cause. As another example of how the tests helped us, towards the end of development we were faced with splitting a fairly complex set of internal data structures, so that a portion of each became available outside of a component (to do with retaining the data over a power cycle). The change didn't actually change any of the existing tests, so despite massive refactoring, when we built and all of the tests still passed our confidence was high. Manual testing at the project end found very few problems. TDD had worked!

In early 2015 I used James to train another team of engineers for me, again with positive outcomes.

Over the last year I have been working independently and have coached/trained TDD wherever I have worked. Always with positive results.