Unit testing is essential in order to ensure that your code does what it’s supposed to do.
But, as much as Typemock is a firm believer in unit testing, well, let’s be honest — it’s not fun.
As our CEO recently put it in Dr. Dobbs, “Unit testing is like staying healthy,” argues Lopian. “Staying healthy requires best practices such as eating right and working out. Similarly, development teams need the right practices in order to innovate faster. Just as it’s hard to start working out, many find it’s hard to unit test and thus stop — despite its well-known benefits”
But unit testing frameworks have many problems.
Some of them include:
1. Lack of Automation – Yes, you can write manual tests and do everything manually. You can also code in Notepad or another text editor. For some, that’s fine – witness the text editor wars in Linux – but others prefer a robust IDE and toolkit. Automatic unit testing saves time, allows for more robust testing, and allows for tests to be run repeatedly. But even many automatic unit testing frameworks, like xUnit, or mocking-only frameworks don’t let you test much of your code unless you go 100% by the book with excellent design. Most of us simply don’t have code that can be adequately tested by even the most robust open-source frameworks, leaving us (and our business or product) vulnerable to bugs and technical debt.
2. Focus on test instead of code – The goal is working code, delivered on time. But, too often we forget this, focusing on our tests. But, this allows a disconnect between our test and our code. When a test fails, what does that mean for my code? When it passes, how do I translate that into working software?
Frequently, while we know that a test failed, we don’t always know where the error is. This makes it harder to achieve our goal – getting code out in time that just works.
3. Takes too much time – In our high-stakes development environment, frequently understaffed and overloaded, every second counts. Sometimes, we’re also tempted to shortcut now and save time up front – of course we’ll pay for that later but later is abstract when your boss is breathing down your throat. And, yes, even when you have the luxury of doing TDD by the book on greenfield code, it still takes time up front (of course it will save you time overall, but when the release is due, try telling that to your boss).
Currently, most unit testing frameworks run your entire code every time you make a minor change. If you’ made a minor change, you still need to rebuild your code from scratch. That’s time that you just don’t have when your code is overdue. Each change takes time and seconds turn into minutes and hours.
Frameworks need autocomplete – shaving time – and to just run the code that changed.
4. Weak mocking – Require TDD and good design first – can’t deal with legacy code – Simple greenfield code is a nice fantasy but it’s not most projects. What is needed is a framework that can mock complex legacy code, privates, statics, etc. Most frameworks don’t offer powerful mocking or the ability to test legacy code, new code, or even unwritten code.
5. Coverage – Too many frameworks don’t let you know what’s covered and what’s not. Yes, as Uncle Bob said, coverage is not the most important or only metric and 100% code coverage may not always be the ideal.
But, too often, we don’t know what code is covered and what code is insecure.
Leave a comment – what are some things you find lacking with unit testing frameworks. Feel free to tweet as well using hashtag #tddfail
It’s time for a change.
Luckily, change is coming.
Stay tuned.
Can’t wait? Discover unit testing tools and practices this Wednesday and enter the raffle to win an Isolator license.
