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

51–60 of 450 posts

Re: TDD did not live up to expectations

#51

Post by nikkettt »

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

Playing devil's advocate here: I'd say that algorithm design (Which is what a sudoku solver is) is a bad fit for TDD.

However, I'd argue that most problems in commercial coding are of a more engineering/architectural type of nature. Here, outside-in TDD has it's place.

Outside-in TDD can help you tackle problems that seem enormous, and slowly but steadily break them into smaller components.

Re: TDD did not live up to expectations

#53

Post by sbov »

jcbrand wrote: post #40
atonse wrote: post #8

In the earlier days of the ruby community, I feel TDD was seen as gospel. And if you dared say that TDD wasn't the way (which I always felt), you'd feel like you were ostracized (update: just rewording to say, you'd worry that it would hurt you in a job search, not that people were mean to you). So I never spoke up. I feel like I was in the TDD-bad closet. I absolutely think _tests_ are useful, but have never found a…

My experience is that whether one is writing tests first or not, the code that is being written does get tested one way or the other. In other words, people (for example web-devs) who don't write tests first tend to "test" their code by clicking around in the browser to see whether they get the desired effect. Writing tests, running them and then iteratively updating/fixing the code is IMO so much more efficient than…

Clicking around in your browser is more akin to an integration test though. TDD is about unit tests, not integration tests.

Re: TDD did not live up to expectations

#55

Post by sevensor »

TDD has worked well for me exactly once: porting a library from to Python to C. I had a very clear idea of what every function was supposed to do and I could write tests first. Due to the nature of the library I was able to write tests that generated lots of random inputs and check the properties of the outputs. This was a great experience --- it was very easy to change the internals without fear of breaking something. Ordinarily writing C is a bit of white-knuckle experience, but this made it quite pleasant.

Re: TDD did not live up to expectations

#56

Post by perlgeek »

When reading the title, I had hoped for data. Like when Microsoft analyzed their own developer's data to find out if remote work impacted productivity or bug counts.

Instead, just another piece of anecdote. Sure, anecdotes from 15 years, still not what I hoped for.

Doesn't Microsoft have hundreds of dev teams, and can compare things like development speed and bug counts, and correlate with whether those teams practice TDD? I'd read that article immediately!

Re: TDD did not live up to expectations

#58

Post by dtech »

colomon wrote: post #30

It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type. Working on Perl 6 compilers, an extensive set of tests was our best friend. It was (probably still is, I haven't had time to help the last few years) utterly routine to write tests first and then write the code to make them work. It was a perfect way of working on it. On t…

I think TDD works great if you have a very clearly designed input or interface. A programming language falls under this category: here's a piece of code, make sure it compiles and returns the correct output is a perfect test. And one which you can defined beforehand and is achievable to write as a test.

However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear what the solution even should look like, and the requirements will change over time and are changed based on the software's progress. In this case TDD only slows you down. It's also why short iteration times (i.e. agile) seem work relatively well in software development.

Re: TDD did not live up to expectations

#59

Post by wolco »

jcbrand wrote: post #40
atonse wrote: post #8

In the earlier days of the ruby community, I feel TDD was seen as gospel. And if you dared say that TDD wasn't the way (which I always felt), you'd feel like you were ostracized (update: just rewording to say, you'd worry that it would hurt you in a job search, not that people were mean to you). So I never spoke up. I feel like I was in the TDD-bad closet. I absolutely think _tests_ are useful, but have never found a…

My experience is that whether one is writing tests first or not, the code that is being written does get tested one way or the other. In other words, people (for example web-devs) who don't write tests first tend to "test" their code by clicking around in the browser to see whether they get the desired effect. Writing tests, running them and then iteratively updating/fixing the code is IMO so much more efficient than…

You will miss items if you don't visually inspect even in a ttd application. Tdd is a net to catch some expected bugs but should not be the only tests.
Post reply on HN