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

401–410 of 450 posts

Re: TDD did not live up to expectations

#401

Post by hdi »

I like the general assumption that TDD failed.

Failed at what exactly? Who would think 1 methodology would give them all they need to be a great software engineer?

If TDD supposedly failed, can we hear the process that succeeded at what TDD failed? Please extend an olive branch and enlighten the rest of us.

Because I tell yea, I can't even count the amount of "senior software engineers" I've encountered, that deploy untested production code daily to systems that help you guys buy your coffee in the morning, manage your money and pensions. Oh yea, and they all seem to think TDD is bollocks too.

When that percentage decreases and engineers like that become a rare occurrence, then we can talk again. Peace.

Re: TDD did not live up to expectations

#402

Post by bluGill »

PretzelFisch wrote: post #281
taeric wrote: post #96

Earlier quoted context omitted.

You are still writing the tests first, with no real learning from them other than "they are now passing." It is thought this is like engineering. You design an experiment and then pass it. However, that is not how experiments work. You design an experiment, and then you collect results from it. These may be enough to indicate that you are doing something right/wrong. They are intended, though, to be directional learn…

If you wrote the test after you coded your unit,you would not know why it passed. It could be a false positive. When you move on to the next part of the requirement, you can ensure all your tests still pass. Sometimes the tests give you the starting point of the problem, "what is the simplest way to get result x" with a way to rapidly get feed back that all the requirements are ment as the structure takes form and yo…

I sometimes write tests that I know will pass. A common example is when the previous version of an algorithm had a bug in some special case. My new algorithm written from scratch doesn't have that special case at all so there is no test for it. However because the last version had that bug there is a lot of fear so I will write a test that it works even though it is inherent in my new algorithm that it works and at no point in the TDD cycle is that test the correct one to write.

Re: TDD did not live up to expectations

#403

Post by bluGill »

jacques_chester wrote: post #310
api wrote: post #223

Earlier quoted context omitted.

I guess another way to put it is that TDD is an attempt to do old school "waterfall" in code form. Way back before anyone really understand how software engineering should be done, people would begin a software product by attempting to pre-specify ahead of time every nuance of the system. They'd write these massive books of requirements. Then they'd get to work coding to these requirements. This rarely worked out wel…

Your description does not resemble TDD as I learned it and practice it. > As such the tests often end up containing bugs All code contains bugs, but we do not abandon programming. Having statements of behaviour from outside and inside the solution increases the chances that one will reveal a meaningful difference from the other. > I just think the 100% test coverage TDD dogma is oversold and doesn't really work well…

Test coverage doesn't make sense to a TDD shop and so they never talk about it. The only code they have not covered by tests are things that cannot be tested at all. They by definition are as close to 100% coverage as you can be.

Test coverage is important in shops that do not do TDD. Such shops are learning the hard way that they need tests to ensure that existing features do not break when they add a new feature. Test coverage is a metric they can use as a proxy for how likely it is that change will break something else (fixing a bug and introducing a new one is a very real problem).

Re: TDD did not live up to expectations

#404

Post by BeetleB »

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…

>Object-Oriented decoupling through dependency injection makes mocking a lot easier (and removes the need for mocking frameworks)

I'm confused by this. In C++, I found that one of the only ways to effectively use mocking was via dependency injection. For us, dependency injection was introduced to enable TDD. That it had other good qualities was a bonus.

Re: TDD did not live up to expectations

#405

Post by talles »

srcmap wrote: post #235
lliamander wrote: post #191

Earlier quoted context omitted.

It's worth noting that Kent Beck ("Father of TDD") himself said that TDD doesn't always make sense. For him, the important thing has always been having a tight feedback loop for determining if he was still on the right track. For instance, when he was working on an unstructured log parser, there was no way TDD would work because the logging stream didn't have a pre-defined structure. Instead, he developed a process w…

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

Aren't you conflating TDD with just automated testing?

Re: TDD did not live up to expectations

#406

Post by BeetleB »

kazinator wrote: post #296
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

> TDD always worked for me. > All successful projects in my career had full functional regression test coverage. Regression testing is not the definition of TDD, however. TDD is this crazy religion of writing tests for everything, including the lowest-level helper functions in a module that don't correspond to anything that would be tested in a regression test suite. You write these little tests first (which must be…

>TDD is this crazy religion of writing tests for everything, including the lowest-level helper functions in a module that don't correspond to anything that would be tested in a regression test suite.

And like all crazy religions, the followers ignore the prophets.

Robert Martin is likely the biggest evangelist for TDD, and he does not advocate what you say.

Re: TDD did not live up to expectations

#407

Post by ajeet_dhaliwal »

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…

I think the failures are due to a combination of engineering, economic and human reasons.

TDD is counter intuitive to how most people think and work. They think of the features first, implement them and then once it's working want to have tests to ensure it stays working, especially with continuous delivery, testing is mostly about checking for regression as high frequency iterations are done.

Even if things starts out ok, often at some point, some person in the team breaks the flow. You have to be quite rigid about procedure and in my experience most teams don't have the discipline for it. This is especially true when there are business pressures in some companies that put pressure on the development team. We've all experience instances where a program manager or producer asks for estimations and an inexperience developer only considers the coding time. To be honest, unless you're working at one of the top tech firms where everyone is interested in solid engineering and there's adequate revenue to enable this, I still find even basic automated testing in general is still a struggle to have in some companies. The reason for this is because the increased development cost is difficult to measure and so it's absorbed as a cost. They don't realize how much development is costing because they cannot compare it to the alternate reality where they did things a better way. Whereas feature issues are obvious to see for everyone.

Re: TDD did not live up to expectations

#408

Post by BeetleB »

bitwize wrote: post #340
i_feel_great wrote: post #313

Earlier quoted context omitted.

> TDD is this crazy religion of writing tests for everything, Not true in my experience. You should only test code you wrote that can break. You do not test core functionality, the OS underneath etc. You do not test the test themselves.

No, TDD means that if there is a line of code anywhere that was not written to make some failing test pass, that code is by definition broken. ALL code must be against some test, else it's not TDD. And if you want to write code for which there is no test, you must write the test first, run the test suite to see it fail, and then implement the code that will make the test pass. Anything else is not TDD.

>No, TDD means that if there is a line of code anywhere that was not written to make some failing test pass, that code is by definition broken. ALL code must be against some test, else it's not TDD.

Robert Martin is likely the biggest evangelist for TDD, and he does not advocate what you say.

Why do people keep claiming you have to test every line of code in TDD?

Re: TDD did not live up to expectations

#409

Post by he0001 »

For me TDD is mainly three things. Firstly it’s about testing myself so I’ve understood the task properly before writing any code at all. In this step I also can tell if my code is doing too much and therefore can tell if my method or function conforms to the “single responsibility” rule. Secondly it’s about maintainability and logical reason. A codebase where I don’t know what it’s supposed to do, or forgot about it, I can always rely on the tests to skip the parts that’s not interesting making me to move faster. Thirdly it’s about the ability to refactor and therefore evolving design. Even if this is a step in TDD you will always need to refactor since requirements changes over time. The solution you had is not the optimal solution anymore and therefore you must refactor anyway. Evolving design is a strength where you continuously strengthen your code while getting work done faster and faster since you can offload the reasoning on the tests, covering your back.

AFAIK TDD is actually the only way to produce code in a systematic way. When reading TDD driven code I can make certain assumptions which I cannot do with randomly produced code (there’s no system to the code). TDD code is developed automatically with tests in mind and are always a lot easier to test when you need to do it, and you always need to do it. (I would argue that there is possible code which is not testable as is, unless you refactor and then you don’t know what the code is doing the same thing as it did before).

If your tests get coupled with the code, I’d say it’s because either your method/function is doing to much or it’s a language problem, not giving you the necessary tools to ignore implementation details, which mocks usually are an indication of.

Since TDD is a systematic way of producing code (at least more systematic than not doing it), code which isn’t produced with TDD will not play well with TDD produced code since it won’t follow the same conventions, designs and possibilities.

TDD doesn’t automatically make the code more bug free, but I don’t believe that TDD cause more bugs just because you use TDD.

If programmers cannot learn or deal with TDD, you have a different problem on your hands.

Re: TDD did not live up to expectations

#410

Post by alkonaut »

His argument is basically that with tight coupling, TDD is too hard and time consuming to pay off.

But part of the point of TDD is ensure that all code is testable, and testable means loosely coupled.

So you can't start TDD'ing on a bad and tightly coupled legacy codebase. You can do it on a greenfield project however. Greenfield is very much the "lab environment" he talks about. You control everything.

With greenfield projects comes another reality though: you often have to explore and sketch a lot. TDD does not work well for writing a dozen sketch solutions to something and throwing out eleven.

And that to me is the main drawback of TDD: it works poorly for very young code bases and it works poorly for very old ones (that weren't loosely coupled to begin with). It's a very narrow window where you can start using TDD in a codebase and that's when the architecture is first set, but the codebase hasn't yet grown too coupled. Such a narrow window means it's not very popular, for good reason.

Post reply on HN