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

381–390 of 450 posts

Re: TDD did not live up to expectations

#381

Post by ngoede »

taeric wrote: post #64
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…

No. TDD failed for engineering reasons in addition to economic ones. The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for. To that end, if TDD were focused aroun…

That is not at all the assumption. The assumption is that you have some idea what you want a particular piece of code, method, or class to do and you write a test for a small piece of that and then after it passes you do that again.

At no point does TDD suggest you should know all the tests you want upfront. In fact I would expect if you know that then you don't need TDD. TDD is about learning what tests you need and what you want the object or code to look like one small piece at a time.

Re: TDD did not live up to expectations

#382

Post by Udik »

taeric wrote: post #64
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…

No. TDD failed for engineering reasons in addition to economic ones. The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for. To that end, if TDD were focused aroun…

Aren't you two saying the same thing? TDD works when the requirements are well defined upfront, which in the case of fixing existing system is provided by the system itself. But writing new programs is exploratory in nature: you don't know the exact requirements or shape your software will take, and TDD shifts a lot of precious money, time and attention from the what to the how. Which to me, I agree with you, is an engineering issue before being an economic one.

Re: TDD did not live up to expectations

#383

Post by [deleted] »

taeric wrote: post #64
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…

No. TDD failed for engineering reasons in addition to economic ones. The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for. To that end, if TDD were focused aroun…

[deleted]

Re: TDD did not live up to expectations

#384

Post by deweller »

globuous wrote: post #371
deweller wrote: post #369

I grant the premise that TDD has drawbacks. But are they really worse than the drawbacks of not writing tests? Code with no test coverage will have more defects and will be more prone to regressions. For many projects TDD is the best we've got until something comes along that replaces it.

I thought TDD meant doing tests before implementing code rather simply testing code. So I always assumed someone testing his code wasn't necessarily TDDing, and that someone not TDDing wasn't necessarily not testing, just that she tests after implementation. Is my understanding of TDD wrong ?

You are correct.

I incorrectly interpreted "don't do TDD" as "don't do tests".

Re: TDD did not live up to expectations

#385

Post by unclebucknasty »

lliamander wrote: post #241
srcmap wrote: post #235

Earlier quoted context omitted.

TDD always worked for me. All successful projects in my career had full functional regression test coverage. For those successful projects, I made following conclusions: * My personal TDD process are: * Script enable - always run every night, every weekends. Output to html files to see overall green/red in

Sounds like you're doing the right thing. Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) but that doesn't matter. What matters is that: a) you are disciplined in your commitment to quality b) you offload as much of the tedious, repetitive work to the computer as possible. Regarding unit tests and mocking, I have a similar opinion. I tend to test at the larger comp…

Mocking is an aspect of testing that grew out of control and the cost can easily outweigh the benefits.

In addition to mocking frameworks, I've also encountered home-grown solutions that were complete time-sinks to use. At some point, you're investing huge chunks of time, not just testing, but mocking in particular.

It can literally layer an entirely different problem domain onto your dev effort, apart from the actual "business problem" the code is intended to solve.

At a certain point, it's like, "wait, what are we doing here again? There has to be another way." Always wondered how people became so dogmatic and determined that they fail to see that they are veering from their original purpose. There is a balance to everything and something about the dev community causes us to lurch in different directions, well beyond that balance.

BTW, there is a post [0] that reminds me of this on the blog you shared. Good blog, BTW, even if it is no longer active.

[0] http://prog21.dadgum.com/56.html

Re: TDD did not live up to expectations

#387

Post by sametmax »

Another reason for the failure of TDD is the fact you need to be a very good programmer to be productive with it. Indeed, it requires you to be able to think your general API and architecture ahead.

Junior and 9-to-5 programmers suck at this. They are much better at tinkering until it forms a whole, then shape that into something that look decent and works well enough.

And we live in a world where they represent a good part of the work force.

You can't expect everyone to be a passionate dev with 10 years of experience and skilled in code ergonomics and architecture design while being good at expressing him/herself. That's delusional. And armful.

Re: TDD did not live up to expectations

#388

Post by mledu »

If anything I think this article makes a great case for TDD. If your developers aren't good at design and refactoring and that is showing up in your tests, that is an indication that your design needs to be refactored to be less coupled. TDD isn't a panacea, developers have to have some level of sense and see the signs of a less than optimal design. Pain in test creation is a great way of showing that as it simulates client code.

I also don't understand people thinking that you have to write the entire test suite up front. You build your test along with your code. You start simply and build up, this way if you don't have concrete specs your tests are helping you with the design by thinking about consumption as well as implementation.

Re: TDD did not live up to expectations

#389

Post by weberc2 »

shubb wrote: post #370
weberc2 wrote: post #123

The main benefit for TDD in my mind is that it mostly makes it painful to write spaghetti code. When I'm reviewing something that looks too integrated, I just ask for a unit test for that particular piece of functionality, and the author is effectively forced to go back and refactor. After going through this a few times, they learn to think about their design before they write code. Of course, many dynamic languages…

Interesting that you mention dynamic languages. I think that a lot of why people do TDD is that you can't reliably know if a program in a dynamic language has basic issues unless you run it. The same is partially true for manual memory managed languages. You need to push towards 100% coverage in order to replicate the advantage you get in a statically typed language like Rust.

Yes, the better static analysis you have, the less you need to depend on runtime checks, but Rust makes a lot of tradeoffs which ultimately make it a poor choice for most application development (steep learning curve notwithstanding). There's a whole suite of static functional languages that give you the same strong static guarantees, but without the headaches of borrow checkers, lifetimes, boxes, etc, etc. Beyond that, there is Go which gives you some rudimentary static typing (a 99% improvement over dynamic languages), world-class tooling, a great deploy story, etc. In my mind, Go is the sweet spot for the demands of modern application development.

Re: TDD did not live up to expectations

#390

Post by lobut »

globuous wrote: post #371
deweller wrote: post #369

I grant the premise that TDD has drawbacks. But are they really worse than the drawbacks of not writing tests? Code with no test coverage will have more defects and will be more prone to regressions. For many projects TDD is the best we've got until something comes along that replaces it.

I thought TDD meant doing tests before implementing code rather simply testing code. So I always assumed someone testing his code wasn't necessarily TDDing, and that someone not TDDing wasn't necessarily not testing, just that she tests after implementation. Is my understanding of TDD wrong ?

I always thought it meant DRIVING the design as well.

The term TDD gets conflated with unit testing, and testing in general that it gets quite confusing have a discussion without going into hyperbole.

Post reply on HN