Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Giving up on test-first development

iansommerville.com

Post reply on HN
Print view View original

151–160 of 224 posts

Re: Giving up on test-first development

#151

Post by falsedan »

nostrademons wrote: post #8

TDD is nuts for code without a client or specification. The whole point of tests is to ensure that the code does what it's supposed to do. When you have neither client nor spec, how are you supposed to know what the code is supposed to do ? There is, IME, a >90% chance that any such code will be ripped out and replaced as you develop a better understanding of the problem domain. I've found it's pretty useful to go ba…

  > TDD is nuts for code without a client or specification.
So, write/pretend to be one? I find writing high-level overview docs, and API interface example code before writing code gives enough guidance for my personal project to then write some tests & then code (in any order).

Re: Giving up on test-first development

#152

Post by hsitz »

ivanhoe wrote: post #17
ekidd wrote: post #5

From the article: Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests. Interesting. I've often found that the lack of tests leaves me absolutely terri…

From what I understand author is not questioning the usefulness of testing, just TDD approach of writing tests first. I personally prefer a sandwich approach, I start with code first, and then write tests for it as soon as I have that little piece of logic finished (usually a method or two). Then I add more code, followed by more test, and so on. Works great for me and my team.

My impression, too, the author explicitly says he understands value of unit testing and will continue to do it, but he's going to give up on the idea of writing tests before he writes the actual program code. Strange, from what I can tell 90+ percent of comments in this thread treat the author as if he said he was giving up tests entirely.

Re: Giving up on test-first development

#153

Post by Chris2048 »

jacques_chester wrote: post #50

> I won’t spend ridiculous amounts of time writing tests when I can read the code and clearly understand what it does. Is he arguing that simply trusting yourself not to make mistakes is a sufficient guarantor of quality? Ian Sommerville is the author of a famous textbook on software engineering, so it would be surprising if he was. TDD is actually much more difficult in practice than people realise. I read Kent Beck…

What changed at Pivotal labs?

And what do you get with regards to specs? It seems to me the methodology fits how requirements are derived.

Re: Giving up on test-first development

#154

Post by pbreit »

vinceguidry wrote: post #141

I like the idea of TDD, but I rarely use it. The problem is that TDD works well when you already know what you're going to build and how, that way figuring out how to put new code under test isn't too onerous. If the company is paying you for it, absolutely take the extra time to TDD, and do your best to maintain the test base. That's what they're paying you for. If you're greenfielding a side project, TDD is only go…

TDD feels completely unnatural to me. I, like I suspect most humans, want to build and have a thirst for results.

Also, I think it's a solid point that TDD can overly influence your program design. Program design should typically be mostly driven by end user needs/desires.

Re: Giving up on test-first development

#155

Post by mbrock »

Chris2048 wrote: post #142
jamestenglish wrote: post #79

Earlier quoted context omitted.

When I finally decided to really decouple and mock dependencies and create "pure" unit tests was the major "Ah ha!" moment of TDD. I had been trying it out here and there but never really saw the benefit because I wasn't really creating nice testable units. It is hard to say for sure, because the author doesn't give any specifics but wording like: "You therefore are more reluctant to make large-scale changes that wil…

If you move functionality around between methods, or combining, breaking up methods, won't that mean fixing all those unit tests?

Sure, and that fixing is the process of making sure that the code still works, and that you still have the test suite as a second client of the code.

As with everything there are costs and benefits!

A lot also depends on the quality of your tests. If the team doesn't care about test quality or doesn't know how to write good tests, you can easily get these big blobs of incomprehensible and tedious tests...

Re: Giving up on test-first development

#156

Post by striking »

jerf wrote: post #146
talles wrote: post #107

I think we're in this world I'd like to call guardrail programming. It's really sad. We're like "I can make change because I have tests". Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time". Gotta love Hickey.

Who drives their car through an n-dimensional manifold full of Turing chaos? When programming is as easy and as safe as navigating an essentially 2-D Euclidean space, let me know.

Do I have the language for you. https://scratch.mit.edu/

You can make compelling interactive things probably without even making a loop.

I think that's the closest we're going to get, at least.

Re: Giving up on test-first development

#157

Post by jmathes »

TDD is best when you're writing code that talks to other code. So APIs, database models, etc. Pure functions, and code that has dependencies you can inject and mock. You should never abandon TDD in situations like this.

It's true that it's harder to write TDD for code with side effects or that draws UI. It doesn't really make sense to use TDD for this.

You shouldn't conflate the two. Also, "always pass the majority of tests" is a trap. You should always pass all the tests.

Source: I've been managing and working in automated testing and continuous integration systems for 8 years, dating back to before the term was coined. I was the manager of the system, at IMVU, that coined the term "continuous integration". I've also worked on testing at Sauce Labs and Google.

Re: Giving up on test-first development

#158

Post by [deleted] »

jmathes wrote: post #157

TDD is best when you're writing code that talks to other code. So APIs, database models, etc. Pure functions, and code that has dependencies you can inject and mock. You should never abandon TDD in situations like this. It's true that it's harder to write TDD for code with side effects or that draws UI. It doesn't really make sense to use TDD for this. You shouldn't conflate the two. Also, "always pass the majority o…

[deleted]

Re: Giving up on test-first development

#159

Post by lfowles »

crdoconnor wrote: post #149
lfowles wrote: post #126

Earlier quoted context omitted.

Yep, any time I have an assumption about how code should work, that's a good starting point to write a test. Even if it's vaguey like "should not throw when given inputs X Y Z that I expect will be encountered"

That's kind of a waste of time if you're only going to run it once and verification with a REPL or otherwise by hand is easy enough.

That's assuming it works correctly the first time (I haven't had that experience often, even for "trivial" code :( ). Even for "run once" functions, I still use a few tests to develop them and make sure my expectations are correct. With a good framework, setting up a handful of unit tests takes just about as much dev time as running the function in a REPL.
Post reply on HN