Hacker News Reader

Comment by kennethtilton | Hacker News Reader

TDD is overrated and overused, with no regard for the cost of developing/maintaining the test suite. You should join them -- you will probably learn something about building correct software, such as "automated regression testing is not the only way". Ironically, tonight I have fired up the RT I use for one subsystem because it needs work. ie, RT has its place, but the TDD crowd thinks every place is that place. btw, the idea that you would not join a group you like because they do not use TDD confirms what I have come to suspect from interviewing more than a few Rails folks: TDD is a bit of a cult, a tail now wagging the dog of how its adherents think about programming. TDD can be great, but it has its place, limits, and cost.

View on HN

You rail about TDD, but the OP is talking about tests in general, quoting, "They don't test their code at all." I personally thing that TDD is totally backwards and braindead, but unit tests... you just have to have them. The only acceptable time to eschew basic unit tests is if you plan to throw the code away SOON (and have a blood pact about killing it for sure).

Ha-ha, quote further! "They don't test their code at all (and instead run through tests manually..". Actually, I meant to mention that as another sign of cultdom: the verb "test" now means "automated test". Manually testing does not count, nor do any of the other ways we can get to correctnes without TDD.

Automated testing is not necessary TDD.

OK, I'll stop saying TDD. :)

Your conflation of TDD with automated testing is not helpful.

As software developers, the essence of our profession is to automate repetitive tasks. If you have a rigorous manual testing methodology for your software, it should be a trivial task to turn that test specification into automated tests. The absence of a suite of automated tests is a major red flag in any non-trivial software project - it strongly suggests that either the developers do not care about quality, that they do not understand their work well enough to manage quality in a systematic way, or that they are too haphazard and disorganised to manage their project appropriately.

I am just waiting for someone to ask, "How else can one achieve correctness?" :)

But cults do not do that, they just accuse non-believers, in this case, that they do not care about correctness.

That's like saying Messner and Habeler did not care about safety because they climbed extreme pitches unroped where other pairs roped up and moved one at a time. But M&H were very good climbers and got up and down twice as fast as the others, who doubled their risk of the weather turning on them by being "safe". If you know your mountaineering, the latter is usually how folks die on mountains.

Yeah, it's not about TDD, it's about having your testing be a non-automated checklist (without unit tests where useful)

Granted I am reading between the lines, but I think the OP was indeed concerned that this great new team he found was not a member of the TDD cult. As i just threaded separately, they equated testing with automated testing, and that set of my cult alarm.

as the actual OP, I can definitely say I wasn't talking about TDD. I mean integration tests like "Hey, we aren't double charging this person" or tests to make sure that bugs stay fixed. It doesn't matter to me if you write tests before or after the fact, you just should be testing so you can have some sort of sense of correctness.

That's fine. My point was that for you automated testing is a litmus test that turned you against a successful group of great guys. What I do in those situations is check my presuppositions. Maybe I can learn something.

Did you ask them about their practice? Did you ask how often they had to roll back deployments, or at least take a hit on something automated testing would have caught?

That makes sense. I've found automated testing to be incredibly useful and just necessary to be able to really rework code well. Not using automated testing and having a really fast release cycle seems like a recipe for a lot of pain (and they said that testing was taking them forever).

I asked them about their testing - turns out they were looking to have someone help them develop a way to test their software (so at least they want to do it).

I wish I'd asked them the two questions you listed at the end, they are much better questions than a bland "do you test?". They did break the build some times.

Oh. They actually want to step up their testing game? So why this thread? <g>

btw, I am glad no one asked the alternative to testing -- it would have been more a textbook on software development. <g>

Reply on news.ycombinator.com