Over the last year, members of our team have realised that we need to change the way in which we work, this is both as a team and as individuals. The first stage of this is in the realisation that we are actually doing something wrong in the first place. This is a personal experience of mine with regards to Test Driven Development (TDD).
A key realisation was that we need to ensure that quality is higher; quality is always a word which makes me think: What is quality? How do you define quality? I often think that quality is one of the most subjective words in software development. I’ve come to realise that quality isn’t just about how good the code is. It’s about meeting the customer expectations as quickly as possible – that’s the purpose of our job (the Agile Manifesto highlights this).
One of the key things to quality is that getting through system test shouldn’t be a chore. It should be a pleasant experience and the amount of back and forth between System Test and development is a good indicator of poor quality. (Note: this isn’t the only measure of quality; this article isn’t about code quality). This should be reduced to the minimum. This is twofold:
- It can cause friction between developers and testers.
- More importantly it ends up costing you a lot – of trust, and more importantly money.
Unit testing has been around since the computer was born – well programming was born. I wonder whether Ada Lovelace had Unit Tests. I recall my time at University and that my key lecturer – Tony always wanted you to have test harnesses before he’d accept your code for assignments. This meant you had a suite of tests which ensured you substring written in assembler would work. You’d pass in certain strings and then see whether the expected came out – failingl the test if it didn’t work.
I often wonder where I lost that skill or why I forgot to do it. After I graduated it all became about writing code and getting it in to production as soon as possible. It didn’t matter about the tests; it just mattered about getting the code out as soon as possible. How mistaken I have been. I must have cost companies a fortune; I’ve been for interviews where they asked, “How do you test code?” – press F5 and play around with edge cases was generally my answer. You could see their faces – “What about NUnit?”
Big admission I know. For me over the past couple of years I’ve come to realise that software development is all about learning, the faster that you can learn the more adaptable and more progressive you become as a developer.
It’s taken me about 6 months to get used to Test Driven Development, and get it (nearly) completely embedded in to my development practise. I now feel that I have a better understanding of how to write tests, and write better quality code as a consequence. This hasn’t been easy – it’s been hard work, changing the habit of my entire (semi) professional programming career. Write the tests first, and then write the code to make those tests pass.
It is amazing that it now “feels wrong” to be writing code which doesn’t have a test. How weird I wouldn’t have cared a couple of years back. It’s definitely been a learning experience and something that I am now keen to share with other professionals as well.
Once you become passionate about a technique it can quickly rub off on to other people.