Integrity, Unit Testing and the Karate Kid

This week’s #FridayNightWisdom was about Integrity – practicing the values you profess.

As part of my role, I encourage others to embrace extensive unit testing. I extoll the virtues of automated regression tests. I sing the praises of integrated static code analysis tools for increased quality, and reduced software risk. This week, I decided I needed to walk-the-walk, not just talk-the-talk.

Our automated CI pipeline outputs a static code analysis report which highlights coding risks and potential vulnerabilities. I decided to address one of the warnings myself – to show the team how it’s done. It was a very small change and very low risk. I could have made the code change, checked it in and nobody would have noticed. But that would have meant avoiding all the processes, checks and balances of which I am trying to teach my team the importance. I had to approach the problem in the way I’d expect others to…

…I started test-first. TDD for a single line change to a single method on a single class. My C# is a little rusty but I managed to create a new test library and added two tests to assert the current behaviour of the system. Next, I removed the single line of code that our static code analysis tool had suggested to us was un-needed; proving, with the automated tests, that the behaviour of the application remained unchanged. Result:-

  • Massively reduced-risk of the code change altering the expected behaviour
  • One less line of production code to maintain
  • An ever-so-slightly simpler implementation
  • Lasting documentation of the expected behaviour of the system
  • Protection from regression next time someone feels they need to change that class

Unit testing is a habit. It’s a tough habit to learn and the value is hard to see instantly, which is why it is a pretty hard sell into established development teams. Feedback I’ve received over the years includes:-

  • Why would you add 50+ lines of test code for one line of code change when a simple comment would have protected against regression in the future?
  • Anything above 80% test coverage isn’t worth the effort.
  • End-to-end tests offer far more value, why don’t we just concentrate on those?
In fact, one of my colleagues recently pointed me to this article; Why unit tests are worse than you think It’s about lean testing and the diminishing returns that unit tests offer compared to integration tests, or end-to-end tests. Perhaps I shouldn’t be teaching my teams unit testing at all?

YES, Anything above 80% code coverage offers diminishing returns. YES, You must make sensible decisions about how much effort to invest. YES, there’s incredibly rich (and different) value in integration tests (between components) and end-to-end (behavioural) tests. But NO, that doesn’t mean we can skip the unit testing phase of software development. Not just because of the improved quality, nor the use of tests-as-documentation, but also because of the learning journey we all need to go on. When aiming for adoption of high levels of test automation, we need to learn the basics before we adapt and create our own approaches or make our own decisions about what we should or shouldn’t test. This approach to learning is known as Shu Ha Ri.

Martin Fowler wrote a simple blog post about ShuHaRi for the adoption of agile processes . ShuHaRi is a Japanese martial arts technique for mastering new skills. It’s how I like to teach my teams, and how I like to learn new skills – think Mr. Miyagi from the Karate Kid…

Shu (Obey)

To start with, follow the process and the guidelines to the letter. Concentrate on getting the process right, without worrying too much about the theory of why the technique is used that way.

Ha (Detach)

Once you’ve mastered the basics, start to learn more about the principles and theory behind why we do what we’re doing. Start learning from others about new ways of approaching the same process or technique.

Ri (Separate)

Once you’ve learned and applied a range of different adaptations on the same skill, now you’re ready to start creating your own way of doing things. Adapt the process or tools to meet your own needs… then share them with others so that they can learn from you.

With many agile practices such as unit testing, I’ve seen teams try and skip the Shu and Ha stages of their learning; this results in mistakes and a lack of adoption – the messaging and meaning behind the practices is lost. Even as I teach others, I’ve tried to fast-forward Shu and Ha (based on my own learning and experience) but it tends to result in the same mistakes and lack of adoption.

That’s why I believe that we should all practice writing unit tests without trying to find the shortcuts. Be more like the karate kid. Wax on…. Wax off.

comments powered by Disqus