Live data from Hacker News

Test-Driven Development Bypasses Your Brain

stoneship.org

41–50 of 67 posts

Re: Test-Driven Development Bypasses Your Brain

#41

This article misunderstands TDD completely. In TDD, the tests are your specifications . Therefore, any code that passes the tests is formally correct - even though it should always be minimal (YAGNI). In fact, TDD is not simply "tests first". It is: write ONE test, make it pass with the MINIMUM amount of code, refactor, loop.

Usually this makes people go for very simple solutions without thinking properly what are the right data structures and algorithms for the problem at hand.

I rather write proper designed code and write the tests afterwards, before delivering the code.

Re: Test-Driven Development Bypasses Your Brain

#42
post #19

I think the problem mostly spans from the "do the simplest thing that could possibly work"[1] methodology that some practitioners of TDD advocate over thinking about the problem and solving it properly. [1] http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...

The problem isn't the advice, it's the misunderstanding of that advice. Thinking about a problem should happen, and when you sit down to code, you should already know what needs to happen. TDD doesn't propose to replace planning and thought.

Fair enough, I do admit my experiences with TDD are pretty much limited to writing the game of life several times at a code retreat where thinking too much ahead of time was somewhat verboten and talking with TDD practitioners that suggest the best solution to solving a problem is to write some tests, then take some "baby steps" until the problem is solved. I always get the impression it seems to lead into a somewhat absurd situation, such as the one described in [1].

What do you think would be a good reference with regards to TDD practices, as opposed to "I saw some people do it and it looked seriously wrong?"

[1] http://programmers.stackexchange.com/questions/109990/how-ba...

Re: Test-Driven Development Bypasses Your Brain

#43

Earlier quoted context omitted.

You're supposed to refactor your code. Layering tests on top of tests means that you end up spending more time maintaining tests than writing code. Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.

The problem is that that right now in the software industry: TDD, Agile, Scrum, XP etc are a religion. And a lot of people have managed to make their lives easier by making the teachings of this religion mandatory. So what I've been witnessing the last few years is that saying "no I don't think we need a test for this" is a position that will get you no where. So instead every one just puts up with longer and longer…

Come work to the enterprise world where no one cares about whatever the cool kids are proposing.

If the customer does not request for unit tests on the contract, usually no program manager is enforcing people to waste time writing them.

Re: Test-Driven Development Bypasses Your Brain

#44
I find TDD to be useful in two cases:

1. When I already know what I'm doing and it's just a matter of coding what's already in my mind

2. When I'm writing in a dynamically typed language, it forces me to be not lazy and have adequate test coverage since I don't have compile time type safety

I do less of TDD when dealing with a statically typed language and/or when I'm working in an exploratory mode. TDD doesn't help me when I'm just trying out different things to get going.

The thing that pisses me off is when people don't realize that EVERY technique has caveats and try to promote it as a golden rule - a lot of "agile" consultants preach TDD as the golden grail for writing code without any bugs.

EDIT: grammar

Re: Test-Driven Development Bypasses Your Brain

#46

Earlier quoted context omitted.

You're supposed to refactor your code. Layering tests on top of tests means that you end up spending more time maintaining tests than writing code. Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.

The problem is that that right now in the software industry: TDD, Agile, Scrum, XP etc are a religion. And a lot of people have managed to make their lives easier by making the teachings of this religion mandatory. So what I've been witnessing the last few years is that saying "no I don't think we need a test for this" is a position that will get you no where. So instead every one just puts up with longer and longer…

That's an overly cynical take - I've seen both TDD, Agile and Scrum work really well. In any case, refactoring is part of the religion too, so it shouldn't be too hard a sell for you.

And it'll fix build times and broken tests! :)

Re: Test-Driven Development Bypasses Your Brain

#49

Earlier quoted context omitted.

You're supposed to refactor your code. Layering tests on top of tests means that you end up spending more time maintaining tests than writing code. Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.

People always ignore the refactoring. They also look at the time TDD adds merely in terms of individual sessions. They don't look at the project as a whole. > Also, don't test stuff that isn't going to break Hah! =) But how will I prove that i++; is actually incrementing i!

Well, if the incrementing is part of a method somewhere, it probably should be tested, but as part of testing the method, not the ++ itself.

Usually it's more like people testing the basic mechanisms of frameworks or libraries. In some cases it makes sense, eg. if a library that you're depending on is a bit dodgy, but usually it's just a waste of time.

Re: Test-Driven Development Bypasses Your Brain

#50

This sounds a bit like "we don't need no stinking testing", but I know the author is trying to hit at a deeper point. I only wish he had done better. One of the problems here is language: TDD as a general concept can cover everything from high-level behavioral testing to a method-by-method way to design your program. There's a big difference between those two! In general, of course, programming is balancing what the…

Good luck doing TDD with behavioral tests. Running (eg.) Selenium tests repeatedly is only going to slow you down.
Post reply on HN