Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD did not live up to expectations

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

161–170 of 450 posts

Re: TDD did not live up to expectations

#161

Post by eropple »

lgunsch wrote: post #111
eropple wrote: post #27

Earlier quoted context omitted.

This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons: 1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD. 2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code. Writing tests after you've written code strongly encourages you to write implementation te…

Regarding your second point, it is not only very difficult, but also not even how TDD was designed to work by its original creators at all. It is specifically not written by other people. TDD, as outlined by the one who created the technique, as well as other big proponents such as Robert Martin, is done in tight 2 or 3 minute loops. As Kent Beck says, if you can't write your test in 5 minutes, you're doing too much.

How "its creators" designed it to work, and how I find it to work in practice, are pretty different. I've found that having two people understand a spec to the level where they can reason about it (and that the best artifact for demonstrating that reasoning is a test suite) is the most straightforward way to build reasonably correct code.

(I mean, heck. Theoretically, Agile's "creators" designed it to be useful and helpful to developers. Cue sad trombone sound.)

Re: TDD did not live up to expectations

#162

Post by dreamdu5t »

eropple wrote: post #124
dreamdu5t wrote: post #60

TDD: For people who've never used a decent type system. Writing a Solidity test to add two integers today really drove home the point.

The language I've been most effective with when using TDD is Scala.

That's great. In my experience, most TDD has looked like "We're going to need a function or class to do this, so let's write a test that calls all those methods first." Which is absolutely ridiculous when we could just be using languages that have concise semantics to describe what they actually do.

For example, the last HTTP API I wrote in Haskell has no tests. The proper request/response is ensured by the types alone. I've had multiple jobs where I spent weeks writing tests to do the equivalent thing with a nodejs API (the body should contain this, the headers should look like that, etc.)

Re: TDD did not live up to expectations

#163

Post by maxxxxx »

sqeaky wrote: post #85
maxxxxx wrote: post #39

Earlier quoted context omitted.

I also don't understand why people tend to elevate a technique that's very useful for some cases to a religion that needs to be followed always.

People have a constrained view. They see their own problems and have seen the "old" way do nothing but fail and the "new" way do nothing but succeed. What other reaction would you expect? If they actively researched and looked beyond their personal experience then dramatic 0% to 100% Success rates would turn into more reasonable assessments. I think my view on TDD is more reasonable than most of the zealots, but I st…

" have seen the "old" way do nothing but fail and the "new" way do nothing but succeed."

When I look at TDD I see a lot of success but also a lot of fail once people start pushing it too far. To me a fail is when the mock becomes more complex than the real system or a system can't be refactored because the refactoring of the tests takes too long or the tests are just so complex nobody wants to touch them.

This reminds me a little of the situation with OOP. It solved a lot of real problems but then people said "only objects" and you ended up with stuff like replacing a simple switch statement and 100 easy to read lines of code with command patterns that had the implementation spread out over 10 different files.

Re: TDD did not live up to expectations

#164

Post by moron4hire »

andybak wrote: post #141
moron4hire wrote: post #62

Earlier quoted context omitted.

Like the author in the original article, I used to be all about TDD. Now, I like to tell people that "I'm apostate in the ways of TDD". I specifically use the language of religion because I think strict adherence to TDD is itself a religion. I somewhat disagree with the statement he makes, "we know that most developers do not have great design/refactoring skills". I've certainly worked at places that all but ordered…

Interesting that you mention REPLs. I wonder if the often maligned Python docstring concept has/had more merit than it is currently given credit for.

I was not aware that docstrings were controversial in Python.

Out of inspiration from Python docstrings, I have been occasionally working on a JavaScript structured documentation format that I call Pliny: https://github.com/capnmidnight/pliny

It's all about creating a database of documentation that can be rendered to arbitrary formats. The documentation pages on the website for my big project are all completely generated by Pliny.

I made it executable code rather than comments because I could iterate faster on the idea if there were a simple syntax to construct the database structure at the same time as writing the documentation, as well as by including the right setup script, I could have the database live-queryable in the REPL without any additional processing step.

Unfortunately, there's nothing to verify that the documentation matches the code. There is a lot of type information there that would be super useful to exploit to statically analyze the code, but that'd be a big project to add that. It'd almost be easier to convert all of the code to TypeScript and recreate Pliny to extend a generated .d.ts typings file, so the doc gen could use just the typings file as the database.

Re: TDD did not live up to expectations

#165

Post by neuromantik8086 »

norswap wrote: post #16

TDD never worked for me, I believe because of the nature of my work: research code, very explorative in nature. I do not now in advance how the interface will turn up, so it's hard to anticipate the interface in my tests (or it leads to a lot of wasted). Nowadays I mostly test with "redundant random generation testing": generate random but coherent input, run logic, then... Either I can reverse the logic, and I do th…

My former lab tried to use TDD. I've come to the impression that it's not the right approach for science / prototyping and just bogs you down. I don't think that science should eschew testing completely- I just think that something like your "redundant random generation testing" is more in line with what needs to go on. The trickier issue is changing your lab culture so that it actually understands the need to run tests of some kind consistently / with discipline.

Re: TDD did not live up to expectations

#166

Post by hinkley »

reitanqild wrote: post #121
hinkley wrote: post #103

Earlier quoted context omitted.

I was quite comfortable with refactoring for a very long time before I started doing tests, and I think that colors my approach to the problem space. I write code until it misbehaves the first time, and then I start writing tests, comfortable in the knowledge that in another half hour this code will be unit testable and look better than what everyone else is turning in, and that I'll spend 20 minutes at the end clean…

What language?

In this case a bunch of former Java devs touching Java for the first time in a while. There could be something to that.

Could be they've forgotten how, but this isn't the first experience like this. I am doing fine with the tools even though they don't do everything when the language is not statically typed).

Re: TDD did not live up to expectations

#167

Post by swift »

IgorPartola wrote: post #152
nostrademons wrote: post #37

TDD failed for economic reasons, not engineering ones. If you look at who were the early TDD proponents, virtually all of them were consultants who were called in to fix failing enterprise projects. When you're in this situation, the requirements are known. You have a single client, so you can largely do what the contract says you'll deliver and expect to get paid, and the previous failing team has already unearthed…

> Software, as an industry, generally profits the most when it can identify an existing need that is currently solved without computers, and then make it 10x+ more efficient by applying computers. Which is exactly how testing should be done. If you have a piece of software that you test so frequently by hand that you could get actual ROI by automating the testing, awesome. If you don't, then what exactly are you gett…

It's all a balance, but one thing to consider is that future maintenance or new development may require changes to that software. At that time, having good tests will help you avoid breaking things in subtle ways. The problem is that when you reach that point, nobody may remember enough about that code to write the tests, so it's preferable to have already written them.

If a piece of software is trivial or isn't core to your business, though, obviously this doesn't apply.

Re: TDD did not live up to expectations

#168

Post by logfromblammo »

Sir_Substance wrote: post #100
s73ver wrote: post #82

Earlier quoted context omitted.

I've never heard TDD being that you write all of your tests up front, before you've written any code. I've always heard it as: When you're writing a class/unit, you write a few tests for what that unit is going to do. You then make those tests pass. You add some more tests, make those pass, and so on and so on.

>I've never heard TDD being that you write all of your tests up front, before you've written any code. That's interesting, because as a non-TDD practitioner who occasionally gets it evangelized to me, that's certainly how I was told to go about it by multiple people. Possibly TDD has a marketing problem?

TDD is writing code to automatically validate that a specification/requirement has been met, before writing the code that meets the requirement.

It does one requirement at a time. You might add a specification that the code has to create a list of strings from a data set. You write a test that takes a data set as input and checks the output to see if it is the expected result. This fails, because the code hasn't been written yet. Then you write the simplest function possible to make the test pass.

Once it passes, you check to see if anything can be refactored. You can refactor as much or as little as you like, provided that all the tests still pass. Once you're satisfied, you write another test for another requirement. It's like a spinning ratchet wheel, where the test suite is the pawl. It keeps you from backsliding, but you can't spin too fast, or it flies off and won't engage with the wheel. Turn-click-turn-click-turn-click.

Writing all your tests up front is one of the worst ideas I have ever heard.

Re: TDD did not live up to expectations

#170

Post by willvarfar »

mjw1007 wrote: post #156
willvarfar wrote: post #9

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/ , is complete without mentioning the TDD Sudoku Fiasco :) Ravi has a nice summary: http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-so... Peter Norvig's old-fashioned approach is excellent counterbalance: http://norvig.com/sudoku.html

The 'Fiasco' is a bit of an unfair comparison, because Jeffries is deliberately providing a 'stream of consciousness' writeup while Norvig's is a cleaned-up version with false starts removed. (You can tell Norvig's code worked differently at one point by looking at the return value of assign(), for example.)

I would be staggered if Norvig's approach ever wasn't constraint propagation and backtracking.

Solving Sudoku is blindingly obvious even to mere mortals with even a iota of exposure to computer science and algorithms.

Post reply on HN