Why I don’t use TDD or BDD

Is this article satire? His "reasons" are completely invalid.

>>> “Examples” of unit tests suck donkey balls every time.

So lack of good examples imply that the whole system is useless? Yes, an example of "assert True" is useless, but just download any of the thousands of open source projects that use unit tests and look at the code.

>>> They seem to be a great way to spend some extra time doing time consuming, not very hard work.

It's not that time consuming, really. And it being easy work is a good thing. A lot of benefit for easy work!

>>> You have to think about the “evil” business side too.

Running away from your problems is never a good idea. Face the "evil" (whatever that means) side like a man.

>>> Unit tests=more code

OK, there is a difference between useless code and good code. Unit tests doesn't make your system any more complicated or harder to read. In fact, it makes your system more stable and easier to read.

>>> That is mostly because I’m a lazy-ass bastard.

Ah, so we get to the bottom of the problem.

The only real way there has ever been to make sure the computer is following your instructions, is to tell those instructions to it twice. (Non-inferential) static typing is about telling the computer the input and output types of your functions twice. Unit tests are about telling the computer the algorithm (or an equivalent, such as a direct mapping function from a subset of example inputs to pre-calculated outputs), twice. These are both just protoforms of Reliable Computing—the name for the actual software engineering that NASA and friends do, where they make the whole system twice (or more) and then run those systems in parallel to ensure they're always "voting" the same way.

But sometimes you don't need engineering; sometimes you just need a dirty hack. Hacking is basically the opposite of engineering: it espouses DSLs and macros that encode everything exactly once, it prides elegance and other aesthetic factors of code above engineering tolerances. And, of course, it's a lot more fun to do—so it gets people interested in your code, which can actually be the best thing, even more so than engineering it. Linux is a big hack, and because of that all sorts of people enjoy working with it. _why was an eminent hacker, and because of that his code (and tutorials) are still used when getting people interested in coding. None of this code is guaranteed to work, unlike code that has been engineered—but that's okay, in 99% of cases.

Summary: ``I don't get it.''

The parts of my code bases that are the most trouble and the hardest to work with and the parts that have the least testing have the greatest overlap.

I have some bad tests that fail sporadically, but I also have some tests that fail that indicate something is actually wrong and will show up in a production environment in a really, really bad way some day (speaking from experience).

If you're _why, I think you've got a good case for why not to write unit tests. Unfortunately, nobody is _why

I'm ambivalent about testing. I've no fear of not writing tests for something small or scrappy. But.. when I've persevered, weeks into a project they've saved my ass more than once and I've been able to recognize situations where a bug would have previously forced me to spend hours debugging or to release broken software.

TDD isn't a one size fits all technique. But just because it takes time, doesn't always yield immediate benefits, and can leave a bad taste in the mouth at first, it doesn't mean you wouldn't ultimately benefit (even beer shares these negatives ;-)).

The great thing, though, is that there are so many ways to practice testing. If you don't want to go with full on "test first" TDD practices, even rolling out a handful of automatic integration tests could cover your most onerous painpoints (this is my strategy on old projects that have no tests - something's better than nothing). Though TDD's proponents foam at the mouth about always testing, it's not a binary option - you can wade in the shallow end and get into deeper waters over time as it begins to click.

Here's my take on testing:

I'm the kind of guy who likes to get things working as fast as possible. When I'm excited about an app or feature idea, I can't be bothered with writing tests along the way, much less before I write my code. I get much more satisfaction out of writing code, running it in the browser, and testing it the old fashioned way. I build apps and features quickly and this usually makes me (or the client I'm building it for) very happy in the process.

I do, however, understand the value of testing. Unlike the OP I have seen real world cases where testing has been a godsend. I often feel guilty for not writing tests, even if it's just a toy app I'm developing for my own curiosity.

To balance these opposing tendencies of mine, I have taken a ATDD approach to testing, or "Adaptive Test Driven Development". That is, write tests for the most critical components of the site, such as anything dealing with money or sensitive information, and write tests for the parts of the app that get used the most, both by me when I'm developing them, and the users once it's deployed.

When I've gone to the browser for the 5th time to test a feature I'm developing, it's a pretty good sign that an automated test would be more efficient than my manual testing, so I set aside the time to write it. If I know there's a part of the app that errors will be completely detrimental to, I will write tests for that, if only for my own psyche.

To be completely honest, TDD/BDD and some of the rhetoric surrounding it seems a bit ivory-towerish - a way for the templars of hacking to distinguish themselves from the proletariat developers. If I had been told TDD is the only way I could develop a rails app when I first started doing it I probably would have given up pretty early on. So if TDD is getting in the way of your being productive, it kind of defeats the purpose of it even existing.

The important thing is to strike a balance that works for you, and keep an open mind about other developer's habits and tendencies.

Use automated tests for any software where the probability of you working on it in the future is > 0.

Any testing is better than none.

Good testing is better than bad.

Good tests;

* Are relatively simple to write if the design is decent

* Make clear what is being tested

* Do not break if something unrelated changes

* Run quickly

Understand the difference between unit testing, and integration testing. Chances are, you're doing the latter, thinking you're doing the former, and wondering why it's so much work.

Lastly, know when TDD and BDD is appropriate.

For me, it is around the 25% mark; earlier, and I spend too much time fixing the tests as the design goalposts change, later, and I spend too much time fixing bugs that could have been prevented by tests.

It is very much dependent on the kind of code you write. If you write UI code then automated testing might not help you much. But for algorithmic code you can usually write short tests that test very comprehensively and catch nearly all bugs.

For example if you are writing a sorting function you write some code to generate a random array, sort it, and test whether it is sorted.

    n = random int;
    A = int[n];
    for(i in 0..n) A[i] = random int;
    sort(A);
    for(i in 0..n-1) assert(A[i] <= A[i+1]);

Running this kind of test saves you a heck of a lot of time manually testing scenarios, and it tests much more comprehensively too. Tools like QuickCheck make this style of testing even easier by providing ways to randomly generate things and if it finds a bug it tries to get a small example that produces buggy behavior.

I do not see much value in the kind of testing a lot of people seem to do though, for example in a web application putting something in the database and then testing that it's there. If the test is about as complicated or more complicated than the thing it's testing that is a good sign the test is not very useful.

The entire point of writing software is to automate processes that can be done manually, but are too time-consuming and/or hard to do so. Testing is a great example: yes, I could run through my entire application and hand-test it every time I make a change, or I could automate the process and save myself a ton of time and work.

Viewpoints like these are the reason we have a long way to go before software is truly reliable.

I write unit tests so that I can refactor fearlessly. How does the author handle situations where he can either 1) put in a hack to fix a bug or handle a feature request, or 2) restructure the code to make it fit the modified problem description better? If you have unit tests you can do the latter, and feel good about what you have. If you don't have a testing infrastructure, you must do the first, because you have no confidence about how the behavior of the code might change and you have to be paranoid.

On small projects where one has complete ownership and knowledge of the code, one can get by without testing. When you have a large project with tens to hundreds of developers, automated testing gives the developers the confidence and comfort to make large or deep changes with an accurate measure as to the overall stability of the product, even the areas where an individual developer may have little domain knowledge of.

> I just personally haven’t found any use for them in any of my projects or my clients’ projects.

I wonder how that person makes sure that what they deliver actually works. Testing by hand can only get you so far. And when the client calls a year later with some change requests, tests are a great way to know that you haven't fucked up something that used to work because you forgot a small implementation detail.

I think that sometimes people lose sight of the fact that other people are different. You may not care for sports cars while someone else might. Doesn't make one of you superior to the other. Neither one of you can say that the other is wrong and should have made the choice you did.

It is the same thing with many programming methedologies, including unit tests. Maybe unit tests work well for large companies, and I would think they might be ideal for parts of certain types of server applications.

But I have tried the methodology, and found that it slows me down and produces lower quality code. For me, it produces a lot of false positives as the some number of unit tests become out of date each sprint, and the significantly increased overhead slows down development significantly which means less quality functionality per unit time gets developed. I've tested this theory with a real product written %100 solely by me, and found that the actual results in production where there were no unit tests and no design documents (but lots of design "notes") resulted in a shocking result: Not a single exception over a large deployment among thousands of customers and many months and only one reported bug which at the end of the day is actually working correctly but the design decision was not clearly thought out and the software does something the user doesn't expect in a corner case.

Here I see people talking about refusing to hire people who don't believe in Unit tests, and everywhere else on the planet I see people talking about Unit tests as if they are a religion, and as if nobody could write competent code without using them.

But realize this, every programmer is different, and the path to the highest quality code per unit time may not be via unit tests.

This guy has everything backwards. I sort of hate writing tests, but still write them first most of the time. In the end, they catch so many bugs and save so much time, I would never go back to hacking code and point and click testing. The only way manual testing works is if you have an over-financed company with a huge QA department.

boring ...

I like it when people write blogs like this. One question to determine if it was bad satire or not and often times, the interview is over. Makes hiring so much easier.