Live data from Hacker News

Test-Driven Development is Stupid

geometrian.com

151–154 of 154 posts

Re: Test-Driven Development is Stupid

#151
post #113

Just wait until he has to write a system with several hundred web services that have been documented to perform in a very precise manner given particular data sets, and have hundreds of customers who have integrated to that API, and absolutely required that there be no variance in the output in the API, or there (extraordinarily expensive) system integration will fail, at great costs to their business systems. I'm no…

Unit tests are useless for ensuring that a web service API works, they are too low level. You're supposed to be testing only the "units", aka classes or groups of methods.

I stand corrected twice. Probably just goes to show that a non-(current)developer should spend 30 minutes of research on a topic before commenting on a thread.

Re: Test-Driven Development is Stupid

#152
post #126

Earlier quoted context omitted.

Damn. The misunderstanding just goes on and on. TDD is not a unit testing religion. It's a way of designing software. Some have even advocated calling it Test-Driven Design, not Test-Driven Development, because the end result is a design, not a series of tests. This is important to know, because the key factor in the red-green-blue cycle is the blue step: refactoring. The example given by the author is of a system th…

Daniel, there is no misunderstanding, I know about the two definitions of TDD - one focusing on testing and one on design. I think that automated unit testing is a useful method of reducing errors and regressions, however not alone but as part of a series of quality control strategies such as integration and higher level and manual testing, static and dynamic analysis, using higher level programming concepts, etc. I…

I've had a bit of a journey in my professional career when it comes to writing apps. I started in heavy OO-mode, much as you describe, but I'm a long ways from there right now.

We're pretty far down an HN thread, but if you're interested in pursuing this further, I shot about an hour of video to show how I would code a small app. You'll find the three parts here:http://tiny-giant-books.com/blog/technical-story-slicing-1-o...

I'd enjoy continuing the conversation via email if you'd like. Let me know!

Re: Test-Driven Development is Stupid

#153
post #126

Earlier quoted context omitted.

Daniel, there is no misunderstanding, I know about the two definitions of TDD - one focusing on testing and one on design. I think that automated unit testing is a useful method of reducing errors and regressions, however not alone but as part of a series of quality control strategies such as integration and higher level and manual testing, static and dynamic analysis, using higher level programming concepts, etc. I…

I've had a bit of a journey in my professional career when it comes to writing apps. I started in heavy OO-mode, much as you describe, but I'm a long ways from there right now. We're pretty far down an HN thread, but if you're interested in pursuing this further, I shot about an hour of video to show how I would code a small app. You'll find the three parts here: http://tiny-giant-books.com/blog/technical-story-slici…

Thanks, I'll take a look.

Re: Test-Driven Development is Stupid

#154
post #37

Earlier quoted context omitted.

I think I see part of his point, though. By its nature, a unit test is (often, albeit not necessarily) tightly coupled with the thing it is testing--which means that anyone who changes the implementation must change the test, which increases the complexity of code changes. I know that in my own work, the single most important thing for me is to be able to massively refactor, restructure and redesign my and others' co…

Which is why testing behaviour not implementation is so important. Admittedly this sounds easier than it is in practice. Personally I've found that in-memory coarse-grained tests more akin to integration tests, that test from the outside in are helpful and easier to maintain because they tend to be less concerned with the how. I can then choose to write finer-grained unit tests where appropraite

Agreed! A code base I recently inherited (and exorcised) contained unit tests with roughly 90% coverage... And not a single assert. They didn't understand the idea of testing behavior, they just copied the implementation as tests.

I reduced 20,000 lines of tests to 5,000, and caught a dozen bugs.

Post reply on HN