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

261–270 of 450 posts

Re: TDD did not live up to expectations

#261

Post by draw_down »

fanpuns wrote: post #217

I appreciate that many of you (including the article author) are coming at this question with a lot of experience. I, however, knew very little about coding a year ago and learned with TDD as part of how I build almost every project. Although I think it's always the case that I might "be doing it wrong", it's hard for me to imagine now writing code without first writing tests. Part of this is, admittedly, that I'm st…

Not doing TDD doesn't mean not having tests!

As far as the beginner angle, it makes sense to me to stick to TDD when learning to code. There are already so many things to learn and understand, that sticking to one way of working would likely be helpful. The question for me would be whether it matters whether that method is TDD or something else; I suspect it wouldn't matter much.

Re: TDD did not live up to expectations

#263

Post by ericgunnerson »

briandear wrote: post #68
sbov wrote: post #53

Earlier quoted context omitted.

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

I disagree. I and others (such as Thoughtbot) often start by writing integration tests first. It’s known as outside-in testing. TDD by started by with low level tests is just backwards. Outside-in helps you clarify the design from the perspective of the user. https://robots.thoughtbot.com/testing-from-the-outsidein

ATDD or design-driven development starts with integration tests first, and can be a great thing if written by the PO, as you can pretty much skip acceptance testing.

It addresses a different concern than unit testing, however.

Re: TDD did not live up to expectations

#264

Post by oelmekki »

fanpuns wrote: post #217

I appreciate that many of you (including the article author) are coming at this question with a lot of experience. I, however, knew very little about coding a year ago and learned with TDD as part of how I build almost every project. Although I think it's always the case that I might "be doing it wrong", it's hard for me to imagine now writing code without first writing tests. Part of this is, admittedly, that I'm st…

Not doing TDD does not mean not having tests, it just means writing them after writing the feature (this has been the usual way for a long time before TDD, although automated testing somewhat got very popular only a few years before TDD).

I too became a big fan of TDD when I was introduced to it by rspec, then a brand new testing tool. But those latest years, I grew tired of keeping fixing my tests despite having no regression in my codebase - just because implementation changed. I quit doing TDD, but mainly because I quit doing unit testing.

Nowadays, I only do integration testing. I've made a chrome devtool extension to generate capybara tests while I'm browsing, so that I can write my feature, then generate a test for it while doing visual QA in literally 5 minutes (this was something selenium IDE was doing in its time, I just made something a bit more modern to replace it). And since this is integration testing, my test won't break as often if I change the underlying implementation to do the same thing. I would even argue it makes my refactoring more pleasant : if I refactor correctly and end result is not altered, I don't even have to edit my tests (if it breaks, it may actually be a regression).

That being said, what matters is what makes you more productive. Don't take our word for it, it may not apply to you. Just keep wondering how you could make things better.

Re: TDD did not live up to expectations

#265

Post by faragon »

Tests are good for detecting code that is not working as expected, using them as a investment/insurance, based on a budget. However, in my opinion, TDD is often more about an obsesive-compulsive religion built on wishful thinking on programmers reaching the excellence by writing tests ad nauseam.

Re: TDD did not live up to expectations

#266

Post by dkarl »

agentultra wrote: post #189
dkarl wrote: post #172

When you look at the TDD evangelists, all of them share something: they are all very good – probably even great – at design and refactoring. They see issues in existing code and they know how to transform the code so it doesn’t have those issues, and specifically, they know how to separate concerns and reduce coupling. I think one of the selling points of TDD, and something I hoped for from TDD, was that causation we…

> I've also seen people mangle well-factored but untestable code in the process of writing tests, which can be a tragedy when dealing with a legacy codebase that was written with insufficient testing but is otherwise well-designed. Have you read Michael Feathers' Working Effectively with Legacy Code ? [0] In his definition of legacy code it is any such code that has no test coverage. It's a black box. There are error…

Yeah, I've read it, I know the definition, and I understand the intention behind adding tests to legacy code. Unfortunately, TDD (meaning TDD as I've encountered it in print and in practice) encourages people to think that "no tests" is tantamount to "no value to preserve" and therefore "no risk of harm from refactoring." Maybe that's an exaggeration, but certainly some TDD practitioners think that they can't possibly harm a codebase by adding tests. Unfortunately, testing requires refactoring, refactoring is redesigning, and if you don't understand the design you're modifying, your changes can make the code less understandable, not more. Tests added after the fact impose the test-writer's understanding of how the system works, which results in chaos if their understanding isn't compatible with the understanding embedded in the existing design.

Also, in spite of that definition, there's a lot more to "legacy" than not having tests. Not having access to the original designer and not having access to the the requirements or domain understanding that influenced development are important handicaps of legacy code that are entirely separate from tests. Certainly tests added during development can capture some of this knowledge, but adding tests after the fact does not automatically recreate it.

These are both examples of the danger of trying to elevate one aspect of software development to a primary and sufficient role. "Take care of X and everything else will work out" has no known solution for software development, and any methodology is harmful to the extent that it encourages people to think that way.

Re: TDD did not live up to expectations

#267

Post by aeorgnoieang »

spdionis wrote: post #90
felipeccastro wrote: post #42

Earlier quoted context omitted.

Agreed, but I would add there are specific scenarios where doing the test first really helps - when you're building a routine complex enough that you can't think upfront how you'll do it, like a complex calculation for example. In that case, at least thinking about the tests first and making one by one pass helps you breaking down the problem into smaller, easier parts.

This is the best situation for a TDD workflow, and the only situation I myself use TDD in. If you have complex calculations or data transformations or you know well the expected input and output of what you're trying to do TDD actually speeds you up by allowing you to iterate faster on your solution. If you're writing glue code between a number of other application components (90% of development in web backends) then…

AFAIK, all of the TDD proponents would agree that lots (most?) glue code doesn't need to be covered by unit tests.

Re: TDD did not live up to expectations

#268

Post by mandude »

PaulKeeble wrote: post #247

Microsofts own study of TDD showed that it definitely improved defect rates and they went fully into developing with it for Vista which is part of the reason for the delays. Nowadays large chunks of the API is automatically tested and this has allowed Microsoft to release changes must more often with a lot less manually testing. So while this individual is finding his local team isn't getting the full benefits, Micro…

Wasn't Vista one of the Windows versions that was known for having bugs?

Re: TDD did not live up to expectations

#269

Post by flashdance »

I develop software for radio towers. This was a very confusing headline and article. I only figured out halfway through that I was thinking of the wrong TDD.

Test driven development is one thing. Time division duplexing is very different. I'll have you know that the latter did in fact live up to its expectations!

Showerthought: I wonder if our TDD codebase is TDD?

Re: TDD did not live up to expectations

#270

Post by Spivak »

stale2002 wrote: post #75
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…

"What I've found works really well is independently writing tests afterwards to really test your assumptions." Sure. If you actually do it. The problem with most companies, and the reason why I think that TDD 'works' is that it forces you to right some tests, any tests at all. Many people, if they don't write the test first, will just end up not making any tests at all.

If that's really the case then why not drop the ceremony and simply TTD to, "write some tests first."
Post reply on HN