More developers are coming around to the idea of writing unit tests for their code. But not everyone is sold. Let's take a look at the arguments for just writing code and either manually testing or handing the app over to QA:
- It takes too long to write unit tests.
- This is really simple code. I could see maybe testing something complex, but this is just a CRUD app.
- Write my tests before my code? Are you kidding me? I've always done it the other way and it's worked out just fine.
Let's take these one by one and see if they are still valid.
Time Argument
It doesn't take long to run the test. I think there is consensus there. But writing units tests and writing code is more lines of code than just writing the code. More lines = more time, right?
Sure, as long as manual testing is less than the automated testing over time. Not just the first time, but for the lifetime of that code.
If I'm using your old assembly from 2004 or web service from last month, I want some assurances it still works the way it was supposed to. If you knew the secret way to manually test it, but have forgotten it, I don't fully trust your code. I have to spend time going over that code and testing it out myself.
Code with a lifespan longer than your memory and availability to manually regression test it benefits from having a suite of unit tests that can be run in milliseconds.
Simplicity Argument
"If the code is really simple, there is no point in writing unit tests."
This is a good point. Unit testing can help work through complex code, but what if the code is really easy?
I agree that there isn't a need to bother testing setting and getting properties and methods that just call other methods. And please don't spend time testing code that is part of the .NET framework or an assembly you bought. That's a waste of time.
But if you're using test-driven development, you start with the functionality, not the implementation. So you write tests that cover the important/core stuff in your requirements. You don't bother testing properties and call wrappers, which are just technical artifacts of the important stuff you are coding. If it's the important stuff, shouldn't it be covered with unit tests?
TDD = My World Upside Down
"Writing test before writing code is crazy talk." I also have had a great career without doing this, so what's the point?
I agree it is crazy. I also agree it's a 180 on the conventional wisdom. And I completely agree that it's harder than just writing the code.
But here's where I depart from the TDD crowd. If you're new to unit testing, I just want you to write unit tests to cover the critical code for now. It might lead you to TDD at some point, it might not. But it's not an all or nothing thing. Let's just try to work in as many tests as we can and leave it there for now. How many tests do you need? What code coverage levels are you shooting for? That's up to you. If you feel good showing the code to your peers and are happy to be held accountable for the quality of your code, you're probably done.
I'll make the case for TDD another time. Just baby steps for now.
