Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 637 posts at DZone. You can read more from them at their website. View Full User Profile

Automated Testing is Cancer

04.01.2013
| 19483 views |
  • submit to reddit

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...

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Nicolas Frankel replied on Mon, 2013/04/01 - 7:04am

Beware irony when it is not readily apparent; when I read the title, I began cursing the author...

Giorgio Sironi replied on Mon, 2013/04/01 - 8:18am in response to: Nicolas Frankel

Nicolas, 

humor articles are common, but this is part of the rules for April Fools' Day :)

Dean Schulze replied on Mon, 2013/04/01 - 10:28am

You crossed the line from irony to reality when you talked about paying the cost of testing up front.  That's a real issue.  When your schedule gets cut and you have tests for code that hasn't been written yet but no longer have the schedule to finish the code you then have a real problem.

It's pretty silly to raise pragmatic issues like schedule cuts in the religious cult of TDD, though.


Giorgio Sironi replied on Mon, 2013/04/01 - 12:10pm in response to: Dean Schulze

I agree that red tests without production code do not produce value. However when following TDD is usually impossible to get in this situation because the cycle of test code/production code is only some minutes long: you can't have more than 1 or 2 tests written on missing code at the same time.

Greg Parsons replied on Wed, 2013/04/03 - 9:16am

hahaha. you had me with the title, and it took a fews paragraphs for me to realize your reverse psychology. Well played I say. 

~QAtester 

Indrit Selimi replied on Wed, 2013/04/03 - 10:50am

Hi,

yes, you are right,  for example I perfectly agree with the "while you would be the branded 'the slow one' ",  it happened to me in one of my previous work experiences not only for the tests but also for the fact that using the same words of the Business people: "we have for the first time an working application..." [it wasn't ironic, they were really happy, it was like a discovery for them]; but for my colleagues of IT division, there was something really wrong with that, having working applications was not the objective.

Moreover, I could add something more odd related to the developing writing tests first. It is related to the concept of temporary code. 

Once some of my (to that date)colleagues asked me to write a temporary solution about a functionality in production and they were really surprised when noticed that I have developed it writing tests first: it should have been a "quick and dirty" low cost activity, why wasting money writing tests? In any case it was a temporary solution until a more definitive and imminent (!) solution should have been deployed.  Right ? *

* After some years my temporary code is still running in the web production systems...no further news received about the definitive solution...             

Giorgio Sironi replied on Wed, 2013/04/03 - 3:07pm in response to: Indrit Selimi

> In any case it was a temporary solution until a more definitive and imminent (!) solution should have been deployed.  Right ?

I've seen even genre-savy people falling victim of this. Any new code that goes into production has to be tested somewhat, and the cost of unit-level tests is not higher than manual testing if you are good at writing tests. What is not comparable is the cost a procedural programmer bears in writing a test with respect to the cost an experienced TDDer does.

Alan Felice replied on Fri, 2013/04/05 - 7:46am

I had to come to 

you throw some code over the fence to a QA team and never have to find out if it compiles or produces correct results!
to understand you were joking us..

I think this is a good article to give to someone that is not even trying to believe in the value of TDD..

And, to the ones that always tell of strict schedule or schedule cuts as a reason to not adopting unit-testing, a real possible solution is to prioritize the features you are working on: always work on the most important (for the client/user/stakeholders). So a schedule cut will cut least important features..

After 4 years of using unit-testing, I can accept to implement a partial application (it's a win-win situation), but not to do it without unit-testing (it will be a lose-lose situation).

Giorgio Sironi replied on Sat, 2013/04/06 - 3:47am

 Originally written on April 1st. :) You're right on the path, delivering 3 features that work correctly is always better than 6 features that don't.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.