I’ve never seen Kent Beck as a crazy rules person. I think his comment from stackoverflow demonstrates this:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

http://stackoverflow.com/questions/153234/how-deep-are-your-...

I have the deepest respect for you and your writings, but exactly how much maximum code coverage have you achieved and sustained for at least a month using automated unit tests ?

Just wondering how long you've visited the region you're writing a travel review about.

Unit tests are about confidence in the software. Automation is the mechanism for sustained confidence. Engineering (and / or fad as you put it) is a vehicle to get there.

You can have 100% code coverage, and still not be testing anything. Unless you're testing thoroughly the right parts, they're a false sense of security.

I agree with that. Its just an (imperfect) proxy measure of the depth / extent of unit testing. Asking how much code coverage is likely to give a better reflection of the effort behind unit testing rather than just a - "have you done unit testing".

> These crazy rules people come up with for "proper object oriented" programming remind me of extreme religious rituals. You have to observe all these stupid little rules or else your code will become impure you and will spend an eternity in code maintenance hell.

What's even more amusing is that the people prescribing these rules aren't even using languages where OO is implemented properly. I will start listening when they start using Common Lisp or Smalltalk for their examples. When they use C++ or Java, it just makes me giggle.

And of course, if you find that these rituals are not working for you, then you "obviously" are not doing them properly.

Are you objecting to cultish behaviour like TATFT (Test All The F'ing Time), or to comprehensive testing in general?

Also, are you objecting only to low-level unit tests, or to "integration tests" as well? (i.e. unit tests with a much larger "unit")

I don't TATFT. My metric for deciding what tests to write is "is it likely to break in a non-obvious manner?" If a breakage in this code will cause the application not to run at all, there's not all that much point in testing that. However, if the code is likely to result in some weird errors that will be hard to track down, I feel writing tests is a very good investment.

I wouldn't write off unit testing and test-driven development so quickly. My personal experience is that sometimes it felt like a waste of time, and when it was, I dropped it. For times when I had a clue of what I wanted to do, but only just a clue, writing the test first was a nice tool for fleshing out behavior.

I think it depends on whether your users can write programs for your program.

I work on a web browser, and every test is worth something. To some degree, we don't care what the test is testing. We want to be sure we don't change it unintentionally, thus breaking the web.