Instead of focusing on how (not) useful automated tests are, we need to admit one thing. They are often a daunting time sink, for whichever reason. You can make them habitual, but it's hard to sustainably enjoy writing them. You wish they took less time and gave more benefit. I bet if that was the case, we wouldn't have so many debates on whether tests are needed.<p>In the recent story about human-powered airplanes they finally came up with the right question: "How can we make the flying machine easy to fix when it crashes?". Imo, here we need to ask the right question as well: How can we minimize the time consumed by test-writing while maximizing their usefullness? Maybe we should drop the practice of 1 assertion per test, or the notion that tests are also documentation. Maybe we should embrace integration tests. Maybe not. Maybe we should strip all the cruft around the point of tests "it helps you think, it documents your code, it leads to better design" and get back to the roots. Tests are there to make sure that critical parts of your code keep working. That's it. It's better that we sustainably write useful occasional tests for critical code than lie to ourselves about how disciplined we are, burn out, and condemn the whole thing.
it sounds like he(?)'s a relatively new programmer whose jumped from a place where they don't test at all to somewhere where they are forced to be written before code.<p>fact is, they're a tool. i don't write tests for everything. and i don't care much if they are unit or integration or regression or xxx tests. i write tests where i know they will help (and i write my code so it can be tested, but how can you separate that from "good design" anyway?). that comes from experience and requires freedom - the freedom to decide when to use them and when not.<p>which sucks if you're new and clueless and in a shop with "rules". but then the rules are there because you're young and clueless and this is your first job where you get to write tests...<p>if the poster is reading this, all i can suggest is: suck it up, get better, and get to the point where you know what to do, and where you're good enough to get a job where you're trusted. it will happen with time, if you stick at it.
Looks to me like he went from one extreme to another and managed to get burnt in the process.<p>I am sure someone else is going to say this but tests are a another tool towards software quality. They are not the only tool to achieve this goal nor are they a silver bullet.<p>They really save you when six months down the track and you are refactoring a fairly hairy piece of code you hammered out to fix some critical bug.<p>This is where I find myself. All critical paths have unit tests (which helps enforce a clean design) and as such I am not afraid to make sweeping changes to the codebase.
"IV) Use the Intel Model. Do not have one product that you iterate on indefinitely. Rather, start over from scratch every so often. ... Intel learns its lessons and carries them over in spirit to the next model each and every time. Even though they start designing the implementation from scratch each time, they in essence remember the important bits from before, and have a Science for reproducing their implementation from their principles and learned lessons."<p>The whole article is worth thinking about, but this is the gem for me.
I think there are three more reasons to do unit tests I wish the author had mentioned:<p>1. Not only do they prevent you from messing your code up because you forgot how it actually worked, they prevent you from having to <i>think</i> about how and whether you've messed something up. I find this to be a creativity boost.<p>2. By helping you maintain the same level of quality, they ensure that if you don't add any new features but keep fixing bugs (and unit testing the fixes), your bug-count will go down. That's a good property for a system to have.<p>3. They give you the freedom to quickly and securely change your design, which in turn means you can keep improving quality, which in turn means you maintain higher productivity in the long run.<p>With this in mind the it seems the author's suggested alternative approaches fall short of what unit tests can do.
An interesting quote from the article:<p>"I will say that I prefer Unit Tests to none when I'm forced to work with stateless programmers who can't remember what they were programming two weeks ago and operate without a design. They'll see a bug, tunnel vision on it, and wreck the whole code base trying to rewrite things to fix it. What's fun is watching them oscillate between two bugs over time without realizing it, fixing one while breaking the other, and vice versa."<p>I have certainly come across cases when programmers created >1 bug while fixing one (chain reaction!), but never oscillations like the author mentions. Has anyone else witnessed this? If so, can you provide an example?
I find unit tests are useful due to a property they share with types, paired programming or formal specifications: you are forced to describe your program in two different "languages", and therefore have to think deeper about the problem. All of the aforementioned methods force one to code, as well as describe the intent behind the code. E.g., a unit test forces the programmer to describe the relationship of input/output, while the code describes the actual mechanism of linking input with output.<p>Code is always the most fundamental "description" of a program, but all the methods have some descriptive power. The process of having two separate descriptions should lead to a higher quality output, as divergences between the two show a possible misunderstanding of the problem, and hence a source of bugs.