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

441–450 of 450 posts

Re: TDD did not live up to expectations

#441

Post by romanovcode »

hdi wrote: post #398
romanovcode wrote: post #357

Oh, finally the TDD fad is dying. Never got into it and always thought it is a complete waste of time. I advocate to write tests only for critical algorithmic calculations and nothing else. Integration tests matter 100x more (at least in webdev).

> Never got into it and always thought it is a complete waste of time. I advocate to write tests only for critical algorithmic calculations and nothing else. What great advice! While we're at it let's advocate surgeons didn't use sterile instruments cos it's a waste of time.. well maybe only for heart transplants.

Yeah, I bet you are one of those who also test your repositories and DB connections while mocking the DB response essentially testing database operations without even having an actual database in the back-end.

Re: TDD did not live up to expectations

#442

Post by borplk »

UK-AL wrote: post #397
borplk wrote: post #218

Unfortunately TDD has become a band-aid for lack of constructs that should be a part of the language in the first place. A language that allows you to express the spec could be so much more useful.

If you implement the feature in the language, surely that language is expressing the spec.

That's not what I meant.

A language could give you first-class-citizen constructs for things like tests and constraints that could be compiler-enforced.

Some of that can be a part of the type system such as the ability to express "positive odd prime integer between 7 and 197".

Some of that could be in the form of other constructs such as function entry and exit guards.

You can "implement" all of that on your own as part of the program but that is not the same thing because semantic meaning and intention is lost.

However when it is a first-class language-level construct it has cascading benefits and tooling can also make use of it.

Re: TDD did not live up to expectations

#443

Post by geezerjay »

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.

No, it doesn't. TDD means tests are written to test the code, and the code being written must pass all tests. It's ok if at any point some parts of the code aren't covered by tests, because TDD is a cyclic process where at each cycle new tests are written to accompany changes in the code.

It seems that the only people complaining about TDD are those who pull the strawman card and portray the process as being unreasonably convoluted and picky, to a level which is almost autistic.

Re: TDD did not live up to expectations

#444

Post by kwhitefoot »

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

> * When any existing test broke, fix/debug the tests are the highest priority before any more features development.

This is the single biggest problem everywhere I have looked. Outside the development team itself no one is willing to wait for a new feature just because a test failed. And for many large programs there will be substantial subsets of users who will not be affected by the bug so they will argue that the delivering the feature is more important, and contributes more to the bottom line, than fixing the bug.

Re: TDD did not live up to expectations

#445

Post by lza »

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…

This!! x100, I am constantly working on features that are not even decided if they go into production. Using TDD for these would be a huge waste of time and energy. Once a feature is accepted I write tests to cover it... after it's already being used and getting feedback from users.

Re: TDD did not live up to expectations

#446

Post by spronkey »

the_af wrote: post #202
enraged_camel wrote: post #155

Earlier quoted context omitted.

Yes, precisely. TDD works for experienced developers who know the problem domain well. It does NOT work for that new junior dev you hired straight out of college. They need to write functions and features first and see the spectacular ways in which those functions and features can fail (in a dev/test environment, hopefully), and then use that experience to switch over to TDD when they write a similar feature/function…

> TDD works for experienced developers who know the problem domain well This is important: it's not only junior devs that fail -- TDD also does NOT work for experienced developers who do NOT know the problem domain well, as the infamous Sudoku solver debacle showed, where Ron Jeffries got too caught up in TDD/refactoring to make any serious progress in actually solving Sudoku.

Amen. And this is what spikes are for :)

I TDD, but I don't TDD my spikes. Sometimes I write an almost working system before I start actually working...

Re: TDD did not live up to expectations

#447

Post by spronkey »

zabil wrote: post #338
ericgunnerson wrote: post #249

Earlier quoted context omitted.

Author here... I agree that time to market is really important, but when a company is searching for the product that will work, the most important thing that you can have is code that is easily refactored, which generally means low coupling. TDD is one way to get there for some people, and it's not 2x the amount of time. My experience is that TDD takes a little bit longer (say 30%) than just writing the code, but my…

Well, there's time you save on testing. TDD gives me quick feedback. Its faster to run unit tests vs deploying and testing the functionality. I'd say TDD adds very little or no overhead.

I would agree most of the time. However in my experience you often end up with at least some small part you have to figure out how to test-drive - i.e. using a dependency. Then you have a choice of "TDD this and write proxies or some other kind of wrapper around everything", or "just go with it".

Re: TDD did not live up to expectations

#448

Post by spronkey »

EpicEng wrote: post #428
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…

This was always my issue with TDD. I never tried it, but I know that the way in which I have written software for more than a decade is "get a loose set of requirements, start digging, write some code, figure out what works and what doesn't, change things, repeat until done." I never saw a way in which I could write a large number of tests up front.

This is basically the workflow with TDD though, and if you're writing a large number of tests up front, you're certainly doing it wrong.

Re: TDD did not live up to expectations

#449

Post by macca321 »

ericgunnerson wrote: post #263
briandear wrote: post #68

Earlier quoted context omitted.

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.

This is the only comment to mention ATDD, and none mention BDD. :(

Re: TDD did not live up to expectations

#450

Post by bluGill »

daxfohl wrote: post #331
chubot wrote: post #145

The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. Not to be smug, but I feel like this is a rookie mistake I learned 10 years ago immediately after starting TDD. The slogan I use in my head is that testing calcifies interfaces . Once you have a test against an interface, it's hard to change it. If you find yourself changing tests and code A…

This is terrific. You know, I've spent the last ten years perfecting coding strategies around unit test frameworks and mocks. I'm really really good at that. Really. I won't be humble; if somebody wants this, then I'm one of the best in the business. Yet, I'm slowly coming to the realization that that's a perfectly useless skill. Perhaps, even a negative skill. It depends on the project, but for most projects I've wo…

I can argue both sides of this (in fact I have).

I would response here that you need to consider your facade design pattern. You should have a facade that you test your code with by careful mocks and fakes. Then the facade translates between your code (which now works) and the API. Particularity if the third party is infamous for breaking changes all the time you want to ensure that when things break you only have to figure out what they changed and fix the glue code.

Of course if all you have is glue code (this is likely: a lot of real world problems are just getting data from one system to another) there is nothing to test.

Post reply on HN