Automated Testing is Cancer
Automated Testing is Cancer
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
One trend is slowly destroying our industry: the requirement of automated testing on the code we write. This madness goes from writing tests before the code they exercise even exists, to requiring code coverage before accepting commits into a development branch.
In this article I will list some of the reasons why you may want to forbid automated testing in your team and your company. It's time to get back the power that you gave a team to be effective, once they get lost in the land of assertions and mocks.
The time investment
Some testing proponents talk about a long term investment in a test suite, which is repaid over time as new bugs are caught. I call BS on this model: you probably won't be around in your current team for the months needed for testing to be a good investment. As the code gets more complex and unmaintainable over time, you won't stick to your current project when you can quit for warmer shores; and even if you do, you can always be replaced by some junior programmer when you need to rework some problematic area of code: he will take the blame for you when that new feature gets stuck for weeks, while you would be the branded 'the slow one' if you try to write tests.
Since we are talking about investments, can we agree about distributing this investment over a long period? Automated testing tries to bring forward this cost to the start of a project or of an iteration, but who wants to employ all of their capital in the first quarter? Aren't you better off by distributing the time you can spend for testing during the months, spending it in many debugging sessions with your colleagues? These sessions also refresh your knowledge of all the old parts of the system that suddenly break.
And what if you can avoid testing altogether: you throw some code over the fence to a QA team and never have to find out if it compiles or produces correct results! This is most certainly the faster way to ship software, and the better way to spend your precious time.
The personal feelings aspect
It's not only a matter of costs: the well-being of the developers in your team is risked by the use of automated testing.
For example, can you compare the emotion of digging into production logs and slaying bugs with how boring it is to write an automated test to reproduce a problem? In many cases tests have to be written even before the system they exercise exists, adding to the time spent for writing them the frustration of not seeing them running for weeks after the fact.
We are not even considering the need to modify tests when a requirement changes. Not only are you exposing one of your colleagues to the cruelty of the client and his requests, but you're making him double his efforts by having to change both code and tests at the same time. The avoidance of these mindless tasks is what distinguishes us from animals.
The social aspect
I've seen many teams where tests were so invasive that the people could go home at 6pm every day, losing the trust and camaraderie that come from nights spent together while fixing code directly on the production servers; never working as a single person to replicate the same exact modifications on each of them.
Can you really compare the team spirit developed by a successful 10-hour debugging sessions using Firebug and logs, with the daunting task of writing a test, an unfamiliar activity to most people? The thrill of going into production is removed from the team - and we all know strong emotions keep people together.
Let me add another social aspect, involving the development team and other departments. What if tests fail? You find yourself exposing bugs no one asked you to look for, let alone to find. You're essentially stopping a release that was going live early because of some bug, and your team may suffer the consequences of trying to raise the quality of their project.
To this stopping-to-fix-bugs impediment, you have to add the clash with other teams, such as Quality Assurance. Do you know how many manual testers are now out of a job because of the diffusion of Test-Driven Development? So many people that were making a quick buck by hitting their keyboards in random spots during the day, are now being cut as their departments are being downsized: once bigger than the development teams, they are now reduced to one or two people per project. But this crime against coworkers will pay its toll.
If the meaning of this article is not clear, check your calendar...
Opinions expressed by DZone contributors are their own.