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

101–110 of 450 posts

Re: TDD did not live up to expectations

#101

Post by willvarfar »

eropple wrote: post #87
willvarfar wrote: post #66

Earlier quoted context omitted.

I find TDD useless as a way of poking at problems I don't actually know how to solve (as Jeffries found with Sudoku), in the way and slowing down when writing large new systems, and excellent when bug-fixing maintenance. Test Driven Debugging!

You can't do TDD when "bug-fixing maintenance". It's a contradiction in terms.

Curious. How so?

Get a bug report.

Write a unit test that reproduces the bug.

Fix the bug.

The unit test now passes.

Check it in. Now its part of your growing regression suite.

How is this not "test driven"?

Re: TDD did not live up to expectations

#102

Post by crucialfelix »

Some code is perfectly suited to TDD. Other code not so much.

I was just working on something with a bunch of tangly functions that measure and remap data and prepare it for sonification as sound events.

I keep jest running and the workflow is much quicker and more satisfying than any other way of hacking.

Re: TDD did not live up to expectations

#103

Post by hinkley »

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…

I was quite comfortable with refactoring for a very long time before I started doing tests, and I think that colors my approach to the problem space. I write code until it misbehaves the first time, and then I start writing tests, comfortable in the knowledge that in another half hour this code will be unit testable and look better than what everyone else is turning in, and that I'll spend 20 minutes at the end cleaning it up even more.

But I am not everybody, and trying to set team policy on my comfort levels is quite likely a bit dangerous.

I've paired with a few smart people this month and was horrified by how they refactor. Most trust their hands more than the tools. They do a LOT of transcription instead of copy and paste, and don't use the IDE's refactoring tools at all. That's not just inviting human error to the table, that's giving it the seat of honor.

For most processes there are ways to do it that are worse than nothing at all, and unfortunately many of us seem drawn to them almost instinctively. I try not to think about it because it just makes me angry that the distance between what we collectively know and what we individually do is so wide.

Re: TDD did not live up to expectations

#104

Post by s73ver »

S_A_P wrote: post #80

One thing I've noticed. TDD takes longer. It just does. You can argue that you are racking up less technical debt in the long term but every consulting gig I've been on where TDD was the "directive" often deteriorated because the business does not want to factor in between 40 and 100% extra time to allow proper TDD coding. They want the same somewhat arbitrary and bonus driven deadlines that they always do, and in or…

Maybe if that bonus was tied to the amount of critical bugs that came back within the next year or so

Re: TDD did not live up to expectations

#105

Post by thaumasiotes »

s73ver wrote: post #82
taeric wrote: post #64

Earlier quoted context omitted.

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've never heard TDD being that you write all of your tests up front, before you've written any code. I've always heard it as: When you're writing a class/unit, you write a few tests for what that unit is going to do. You then make those tests pass. You add some more tests, make those pass, and so on and so on.

It's a very common way to evangelize TDD. Ruby Koans is a tutorial entirely based on that principle.

Re: TDD did not live up to expectations

#106

Post by amirouche »

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 don't do the TDD like a waterfall. I don't do upfront all the tests, there is a discussion between the code (what express the business need) and the tests that "wraps" it inside a safe zone (what ensures that the behavior is the one intended). As such, as the idea grow, both the code and the test grow at the same time. Look at [0] to have an idea of how the tests extend the safe zone along the code.

Also, I much prefer a lot of nice unit tests over a lot selenium tests (which takes a lot of time to run).

[0]https://github.com/charlesthk/python-resize-image/commits/ma...

Re: TDD did not live up to expectations

#107

Post by falcolas »

AnimalMuppet wrote: post #83
falcolas wrote: post #32

Earlier quoted context omitted.

> If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?

You don't have any such guarantees. But your test would have to be broken in the same way that your real code is broken, not in some different way.

Well, if the test is accidentally testing the wrong input/output pairs, your code can pass the test perfectly and still be broken. Especially if you follow the "build to the test" mantra.

Re: TDD did not live up to expectations

#108

Post by s73ver »

thinkingkong wrote: post #11
gkop wrote: post #4

There are at least several other advantages to TDD the article misses: * Faster development feedback loop by minimizing manual interactions with the system * The tests are an executable to-do list that guides development, helping you stay focused and reminding you what the next step is * Provides a record of the experimentation taken to accomplish a goal, which is especially useful when multiple developers collaborat…

Except in order to have a checklist you have to have your design and implementation up front which is out of reach for most developers. If were testing high level results in multiple cases thats cool. But a lot of the time youre going to try different approaches that may modify or involve changing your output.

No you don't. You just need to know what the unit you're currently working on does. And if you're working on it, you should know what it does. If you don't, that's a sign that maybe you need to have a conversation with someone.

Re: TDD did not live up to expectations

#109

Post by luhn »

moron4hire wrote: post #79
heifer2822 wrote: post #49

Earlier quoted context omitted.

I think TDD helps or doesn't help depending on the circumstances. The problem is the people who claim there's One True Way. For instance, if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful. But if you're starting a new project from scratch with loose requirements, or worse yet, building a prototype, starting with tests would be a was…

> if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful. Well, first of all, that's not TDD. TDD is Test- Driven Development. In your scenario, you wrote the test after the code in question. In TDD, the whole point is to write the test before the code in question. So the value in your scenario is only insofar as the test is a useful way…

>> if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful. > Well, first of all, that's not TDD. TDD is Test-Driven Development. In your scenario, you wrote the test after the code in question. In TDD, the whole point is to write the test before the code in question

It's a regression test, which is definitely TDD. The code in question is the fix for the bug, the test verifies that the bug is fixed and will remain fixed.

Re: TDD did not live up to expectations

#110

Post by krmboya »

What about a kind of middle ground, doing a 'spike' when figuring out stuff, what kind of thing you should build, what the design should look like, etc then follow up with TDD to stabilize the identified interfaces and produce tests that act as a system health check?

Ok, for consultants, perhaps they end up doing the same kind of things for different clients to the extent that they can just jump in doing things TDD from the very beginning.

Post reply on HN