Automated testing will add value to your software project

We have read enough about TDD and it’s demise in the last year. Since David published his post about how TDD is dead there have been a couple of flame wars concerning TDD and testing in general.

I believe that TDD is a good thing, but I don’t always practice it, as sometimes you don’t have the time to do it. I know, some of you reading this will say that there you must make time for TDD and that TDD is the only way. Maybe you are correct, but in a startup world there is rarely any time for testing at all.

With deadlines and churning new features each week, one can’t make the time to do proper TDD. And sometimes it seems that TDD is some relic from the past, from the really distant past. There is a nice report called Why Most Unit Testing is Waste that sums it up fairly good.

However, I believe in automated testing, at least having a full integration suite, following the application happy path, and any edge case you find later on. Also I’m not against unit testing, if it makes sense. Payment processing code, of course you will test it. Some code deciding if the label class is blue or red, well, you can probably skip that test if you have no time to write it. Rails controller tests are a great example of procrastination in tests. I don’t have anything smart to work on, let’s write a couple useless controller tests.

Unit testing external libraries is another thing, they should be properly tested, to ensure that their API behaves as it claims. Especially if your library is public, then you have to test it.

Having a thorough test suite increases the application value, and decreases the breakability because any subsequent change you make on an application that isn’t tested is like walking through a minefield. You never know what will break.

I would have liked that I learned this lesson the easy way, by listening to other people having issues when some of their code wasn’t tested and they had to change just one little thing, and something completely unrelated broke. However, that wasn’t the case, I learned it the hard way. With a really bad client, who constantly changed their mind about features (another red flag) we were implementing a lot of stuff, and changing it on a daily basis. Having no tests meant that you expected something else will break after deploy, because you just don’t know what can go wrong.

After I got burned by that, I started writing tests, trying to do TDD, but at least covering the process with integration tests as I went along. And it helped a lot, the sheer confidence when deploying the app that nothing will go wrong is really enough. And the client is better off in the long run, because there is no chance that the code breaks, and no one notices it.

Lesson learned: Don’t obsess with TDD or the proper way to test, but try to test the code as well as you can, have an integration/acceptance suite that you run before deploying, and try to cover as much of the app as possible with it. Don’t overdo it, and don’t test the language or framework you are using. Shaving Yaks is really fun sometimes, but don’t do it on a production application, because someone will read it later on, and think that you have to test every little thing.

2 thoughts on “Automated testing will add value to your software project”

  1. Hi Babino!

    Few thoughts from software tester.

    1. TDD is test driven development. Problem is in word testing. TDD is just one way of software development. It is not testing. Here is James Bach definition of software testing:

    “Evaluating a product by learning about it through exploration and experimentation, including to some degree: questioning, study, modeling, observation, inference, etc.)”

    My question is: Do you still think that you are doing software testing?

    2. Your client does not want to use software to accomplish it business goal. Your client goal is that he had already used your software to accomplish its business goal.

    3. Regarding that there is no time to do TDD actually means you underestimated time needed to finish feature. TDD code is part of a feature. You should code TDD in order to prove yourself that what you just coded (and run that concept in your brain) actually works on real cpu. Edge cases should be part of TDD code. But question is: what is edge case? Amount of 1000000000000000$ or 458983 $?

    4. Want to know more? http://www.testingeducation.org/BBST/

    1. Hi random internet person 🙂

      The main point was to emphasise the value testing brings to the project, and the developers. The client rarely sees the benefits of testing, because it additional time written on the invoice. The client only wants to a) make more money by using your product, b) reduce the pain they are having by using your product, or in the best case c) solve the pain and make more money at the same time.

      Testing and some other geeky mumbo jumbo doesn’t really interest them. When you are selling a product you are not claiming it has 98% of test coverage, but claim that it will provide a good ROI for the people buying it, because we are all interested in it.

      TDD and BDD are only ways of software development, not the right ones, not the wrong ones, just ways. There are many more, some of them better than others, some of them not. The main point is, that you should test, at least the happy path acceptance test, and cover bugs with the same tests when they come up. If you feel you have to do more, do it, there is no real harm in testing too much, except wasted time.

      I really appreciate the stuff you do, because I rarely can grasp some of the weird ideas people have when trying to break software, that is where the edge cases come from.

Leave a Reply

Your email address will not be published. Required fields are marked *