[logfromblammo]

If you have ever read about Carrot in Pratchett's Discworld series, you may have a new understanding of laziness.

Carrot, you see, is so lazy that he exercises every day, because it is easier to accomplish things in a fit body than in one that is fat and weak.

Testing your own code is that sort of laziness. You write automated unit tests so that you will never have to look at or touch that particular bit of code ever again.

Having that sort of laziness will also make you an expert in design, because good design allows you to write concise, maintainable code, which makes your job easier.

[aaronem]

That's not Carrot, that's Victor whatsisname from Moving Pictures.

[logfromblammo]

So it was. Victor Tugelbend. My memory is not what it once was. Or I assume it isn't.

[Udik]

Except that you'll pollute your code with all sorts of design decision and syntactic clutter that make sense only in the light of testing. Except that it will take you so much time to test trivial functionalities, you won't have time to write or just think about them better. Except that your tests won't actually capture all failure cases, but only those you could think of at the moment of writing them. Except that you'll spend a good percentage of your time maintaining tests that break for the wrong reasons - that is, perfectly working changes to your code.

Sure, testing can be extremely useful and important in some cases. I'm thinking of complex engines that power business flows and applications. Testing user interfaces and MVC controllers is hypercorrection and usually a waste of time.

[logfromblammo]

A quote from a Presbyterian sermon published in 1856 eventually evolved into a quote fraudulently attributed to Abraham Lincoln in a 1960 advertisement.

If you have 5 minutes to cut down a tree, spend 3 minutes sharpening your axe.

If you are cluttering your code to make your testing easier, you are attempting to sharpen your axe by repeatedly striking it with the trunk of a tree.

If your tests fail when refactoring working code to working code, your problem is the manner in which you write your tests. I have seen testing done well, and testing done poorly. And in light of the latter, I can see why someone might dismiss developer testing. Having both as a basis of comparison, the shop that used TDD accomplished a task in two months with 3 people that the other shop could never have accomplished in 2 whole years with 15 people.

The bad shop mandated testing, of course, as a cargo cult ritual, but metaphorically, in order to test the shear strength of a single bolt, you had to launch the whole Space Shuttle. I often saw methods written with a boolean parameter called IsUnitTest. I am not making this up.

That was a clear difference between smart-lazy and stupid-lazy. One shop sharpened the axe before cutting, and it was felled on time. The other held several hour-long meetings, decided to cut down the tree with a rubber mallet, declared that it would take about 20 minutes, and assigned the task to me entirely without my input. When I suggested an axe would work better, I was told that the mallet was already decided, and if I used an axe instead, I would be fired. When it was later discovered that I used the mallet to strike a splitting wedge, I was deemed to be undermining the axeless mandate, and was fired.

This is metaphor, but there is no hyperbole. This was the shop that banned me from using lambda expressions in C#, because other developers on the team could not understand them. In 2014.

Be smart-lazy. Do the simplest thing that will get the job done. If automated tests do not make your job easier in the long run, don't do them. If some design pattern would needlessly clutter your code for no benefit, don't use it. These decisions are easy to make when they are not being made for you.