Okay, so this is another follow on point from the TDD session at Code Camp Oz.

So the question was around what happens if I write crappy tests, does writing tests matter if I write crappy tests?

As with anything it's garbage in -> garbage out.

And if you write crappy tests, chances are you're going to write crappy code.

And that's a great thing!

 

Have I lost you yet?

Okay, so most of you probably know that you write the test, write the smallest possible test, to test a unit of work - and prior to writing your code.

You are keeping your methods small right?

 

So, you've written your small test, and it's crappy, and you don't think it's doing things the right way, so you hit go and it fails - red.

Well, that's expected, you haven't written any code.

So you write the code to pass the test, run it again and it's green.

 

But you know it's a crappy test... I mean look at it, it barely covers all the reasoning, maybe you haven't mocked, I mean - you're a professional developer.

So pop quiz, hot shot, what do you do?

Think further about the test and refactor the test!

And surprise, it might turn red - your code smells again!

So you go back and refactor your code.

 

So why is it great to write crappy tests?  Because at least you're writing tests.

What were you doing before that?  Well, most people would probably run the program, and it works on their computer, under this instance, if all the data is right and.... many, many crappy ways to do this and you won't get the same degree of confidence.

Because if you're relying on running something, or having some folks out there test it, then when you come to maintain your code you're not in a place where you are confident that you haven't broken code you have written in the past.

TDD isn't about trying to save you work as far as what I believe - it's about doing the work up-front so you have more confidence in what you are shipping, rather than doing a lot more work maintaining it after it's shipped.  It's about having confidence in the product you're shipping.  It's about thinking about the methods you are designing prior to jumping in and coding them.

And it's really not about never doing anything wrong - it happens, you refactor it and try again.

 

Does TDD save you development time?  Absolutely not.

Does it cost you twice the time, because you have to write tests and then code? Absolutely not, because when else are you testing and are you really ever testing?  Plus there's the benefit that you really sit there and work out exactly what you are trying to achieve (the expectations of the test) prior to going in and coding.  It helps you a lot in thinking about the flow of your program.

 

Should I write crappy tests? Well, it'd be perfect if you wrote great tests, but writing crappy tests isn't the end of the world, as long as you recognise that your tests may not be perfect, and you refactor and fix them as needed. Practice makes perfect after all, right?

 

There's a lot of talk out there that says basically, your tests will never prove that your program works or that it does what you want it to.  Your tests prove that your code that you have written, that the tests cover, passes those tests, and should work the way you have tested them to work. 

And it gives you the confidence that in the future you can run your tests and prove that you haven't changed your code so they're broken.

 

Disagree?  You know where to flame me! :)