To TDD or not to TDD - that is the question

Editor's Notes

• #3: This is an experience report. It is based on my biases, my errors, and my misperception. I share my history not because it is especially relevant to test driven development, but because it may help you understand some of the biases that are implicit in the talk. Most of my time with test driven development was as a manager watching teams practice it. I was the manager of a team that transitioned from waterfall to Extreme Programming in 2003. That team of 10-15 people went “all in” with Extreme Programming. We tore down the cubicle walls. We installed big white boards. We encouraged continuous integration and rigorous test driven development in the Java desktop application we created and released every 3 months. We worked that way for 4 years. It was fun. After those 4 years, in 2007 we were acquired by a larger company. The product was moved to India and we were assigned to a project writing SharePoint extensions in C#. I spent a few years managing SharePoint based development in C# with the same developers who had spent 4 years writing test driven the Java based desktop application. After we discovered that SharePoint was a poor choice for the tasks we were trying to accomplish, I was reassigned to manage the build team for a large database application written in Java. We didn’t write tests ourselves, but we ran the tests created by others. That lasted for a few years and provided new experiences, including running builds for hundreds of developers. After those 6 years, I joined a different company as a director in 2013. The team was creating a Java based replacement for a rule processing engine. We spent 3+ years bringing that Java based rule processing engine into multiple releases. More new experiences, and eventually an assignment to manage a team of C programmers in their work on a message bus. In 2017, I joined CloudBees as a technical evangelist. I now spend my time showing people how to do cool things with Jenkins. I think test driven development is great. I’ve been in organizations where we wrote very few automated tests and I’ve been in organizations where we wrote many, many automated tests. I prefer more automated tests and I prefer tests that are written while the code is being written. We created our own python based continuous integration server in 2003, then switched to Hudson in 2007 when it became available. Hudson became Jenkins in 2011. I submitted tests to the Jenkins git plugin in 2014 when I became frustrated at the regressions I was detecting in new releases. In 2015 I became the primary maintainer of the plugin. In 2017, Stephen Connolly became a maintainer and added some really great multi-branch Pipeline features which he maintains. My history is only relevant to you if it helps you understand my biases. I think test driven development is great. I think everyone should do it almost all the time. However, others don’t always think that way. In particular, the original developers of the Jenkins git plugin don’t work that way. This talk uses history to look at those places where a lack of automated tests, and a lack of test driven development can be good, helpful, and workable.
• #10: This is a period of fast learning and experimentation. There is less code to break and fewer dependencies
• #11: I’m a test driven development proponent. I love test driven development. Yet here we see adoption and delight with code that is definitely not test driven. For the first 18 months of the existence of the plugin, there are no tests. None. All verification is done interactively before a release. How were they so successful? Because users are more important than tests. Interactive testing at this stage is much faster than writing tests.