The other day I read a blog by Uncle Bob. It more or less stated that no matter what situation you are in, writing automated tests will make you go faster. Ok, this is old news I thought, until I checked Uncle Bob’s tweets. A fair amount of people argued against this statement, and that surprised me!
So I started thinking about why there still are fellow software developers that doesn’t believe in automated testing? Have they not seen them in action and understood what they are for? Please, gather around the campfire, and I will tell you one, just one, of my war stories, and then I will tell you why also you should write automated tests!
I found myself of being at the stand-up at a new client just a day or so away from the sprint demo, when one of the team members called out and said “Hey, someone has destroyed my service I wrote last sprint! I was just testing my new features in that service when I realised that it doesn’t work anymore. What is happening?”. After some mumbling and discussing they had an idea, and then after the stand-up, they all hacked away and tried to fix it. The result was that it was fixed, but another service broke down. Luckily, that service didn’t have to be shown at the demo.
I tried to explain that, “guys, if we write unit tests, our build server could run them automatically and alert us when we break the build.” “The what server?” they said with their eyebrows close to the ceiling. So we went about and installed Hudson.
Next sprint, the same story again. Some service had broken down. Of course, no unit tests had been written. This time it was the pressure from the stakeholders that was the reason. “We just have to get this out to the stakeholders now, we don’t have time for writing extra code just for testing purposes!”
Even though the problem stared them right in the eye every sprint, some team members never wrote any kind of automated test. No unit tests, no seleneium tests, nothing. Amazing.
Now, if this little story isn’t convincing enough for you, here are a couple of more reasons why I write automated tests. Surely, they apply on your situation too, right?
I write tests to nail down the requirements
Writing tests are a way of describing the requirements in code. A test that verifies that an object goes from one state to another in a correct manner, describes a part of that state machine, i.e. requirements. Or a test that checks the validation of the social security number. And that is one of the reasons to why automated acceptance testing has become so popular, as it is a way of involving the stakeholders (Product Owner) to write the test specs, and then you can execute them. Automatically! This of course makes the team more able to communicate about the requirements with the stakeholders.
I write tests to drive design
Well, I am not going to explain what TDD is, you should know that by now. But I have to admit, I do not always do TDD. Sometimes I like to start with the implementation straight away. Sometimes I like to draw an interaction diagram on a piece of paper. Sometimes, I use TDD. But I always end up with tests covering the major part of my code (yes, it is ok to skip the testing of getters/setters).
I write tests because clicking around for the umpth time in the GUI is boring
Automated tests run so much quicker. Even running selenium goes quicker! And the build server never complains on having to regression test again and again and again… But that does not mean that you do not need manual testing as well!
I write tests to feel safe!
I want to know when I am done. I want to know that I can change code in the future without being scared of destroying some old functionality. I want to know that no one else is destroying old functionality.
As Uncle Bob says, to go fast you need to go slow. So why on earth isn’t everybody writing tests?
Photo Credit: JD Hancock via Compfight cc
Excellent read.I too agree with that manual testing can be replaced by automated testing but not completely.We cannot completely rely on a particular tool because there are some fields where manual testing provides more accuracy that test tool such as when re-testing is required.