 |
|||||||||
|
|||||||||
|
|
I'm a big fan of unit testing. A related question to "How many tests are sufficient?" is "Why don't we write good unit tests?" While I've seen some people attribute it to purely negative things like laziness or dumbness or lack or care for code quality, I think that misses the mark. While sure, there are some devs who don't write tests for those reasons, I think there are tons of other devs who are hard-working, smart, and do care about their work, but still don't write good or sufficient unit tests. Calling these hard-working coworkers "dumb" isn't going to make anything better. Here are some reasons why a good-intentioned developer might not write tests.
I think I already write sufficient unit tests for my code.
I don't have time - the tests take too long to initially write.
I don't have time - the tests take too long to maintain and/or they keep breaking.
The unit tests don't really add value. It's just yet another buzzword. They don't actually catch the real errors. So it's not the best use of my time.
It's so much faster to just (real quick) run through my feature manually because all the context is already there (the data, the web session, the integration with other features, etc...).
My code isn't easily testable - unit tests are great for business logic in C#, but I write code other than C# (SQL, JS), or things that aren't business logic (like UI rendering), or my code is too complex for unit tests.
My code isn't easily testable - there are too many dependencies and limits. For example, I can't even reference an ASP.Net CodeBehind in a unit test.
The tests take too long to run (the full test suite takes about 10 minutes, even without the database tests it still takes 3 minutes).
I write code that already works, so it doesn't require unit tests.
My code is so simple so that it doesn't need tests. For example, I'm not going to test every option in a switch-case.
Sounds great, but I just don't know how to write tests for my code.
Note that I absolutely don't offer these as excuses, but rather as practical ideas to help understand a different perspective so you can improve things. For example, if someone is working on a 2-million line project that takes 5 minutes just to compile, let alone run any sort of test, they might skip running the tests with a "I don't have time" mindset. Yes, I still think it's overall faster to write and run the tests, but at least it helps you understand their perspective so you can try to meet them half way (perhaps improve their machine hardware, split up the solution, split up the tests, etc...). Of, if someone thinks that unit tests don't catch "real errors", then you can have a discussion with concrete examples. Either way, understanding someone's reasons for doing something will help bridge the gap.
Pleas, "well-intentioned" or "developers with good intentions."
I think your post hit right on the mark. I have read several articles like
this, and yours is the only one that seems to hit the right reasons. There
are so many blogs out there talking about how great automated testing is,
but 95% of the programmers out there are not doing it!
Hey Rick,
Glad you liked the post. I hear you that automated testing is hard. I think
the best way to get practical results with the automated tests is to (1)
start small, and (2) start on isolated class libraries. If you start by
trying to automate an end-to-end winForm or web UI, it’s too big of a jump.
However, automating a public static IsEven(int myNumber) function is quick.
You’ll also see huge returns here when it flushes out all the boundary
conditions.
@Rick,
