Giving up on test-first development • Hacker News Board

Re: Giving up on test-first development

#141

Post by vinceguidry » Fri, Mar 18, 2016, 5:04 PM UTC

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 going to slow you down. Time spent learning your domain will get redirected to "figuring out how to put X under test", significantly increasing time-to-market. Get your product to market, find product-market fit, and get some resources to re-engineer your product with, and don't do it yourself because you'll have more important things on your plate.

If you're early in your career, spend some time to learn TDD. Don't do it on your own projects, let someone else pay you to work it out. Don't actually use it unless someone's paying you to, but learn how it works, what it buys you, and what it costs.

Re: Giving up on test-first development

#142

Post by Chris2048 » Fri, Mar 18, 2016, 5:05 PM UTC

jamestenglish wrote: post #79

mbrock wrote: post #58

When writing tests is boring, difficult, and tedious, that's a really good time to think hard about the way the program is structured, if you have time for this. The way to make testing pleasant is to extract more and more behavior into units with clear boundaries... realizing how to do this was a major event in my programming career, and I attribute the insight partly to doing TDD. I don't agree with some posters wh…

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?

Re: Giving up on test-first development

#143

Post by Chris2048 » Fri, Mar 18, 2016, 5:07 PM UTC

galaktor wrote: post #16

Illniyar wrote: post #6

Like all things in life TDD should be taken in moderation. It's an excellent process to create stable and maintainable code, but it does not fit every bill. But abandoning it completely on the grounds that it sometimes makes you write "bad software" is a bit weird to me, in fact, one of the main arguments for TDD is that it makes you write better code. I found that it does make you write better code many times. So li…

I like to think that, like with any other technique, with experience comes the ability to decide when not to apply it. Any old tutorial will show you an example of when it works, but only with experience will you learn when it might not.

Surely a good tutorial could teach that too?

Re: Giving up on test-first development

#144

Post by ChemicalWarfare » Fri, Mar 18, 2016, 5:09 PM UTC

TDD/BDD approach can definitely work and result in higher cohesion between the requirements, design and implementation phases.

The trick is to make sure all phases of the project are factoring this in - requirements with clearly defined user stories and acceptance criteria; design docs where each acceptance criteria is covered, etc.

Another thing to point out is "TDD" is a balancing act between integration and unit tests. There's also a balancing act between the external tests driven by the dedicated test tool and internal tests included into the app.

Re: Giving up on test-first development

#145

Post by kstenerud » Fri, Mar 18, 2016, 5:17 PM UTC

rapala wrote: post #137

andrewfromx wrote: post #71

C.S. Degree in 1996, 20 years "professional" programmer and I never once thought TDD was helping my project. Every time I did it, it was because the boss told me I had to. Litmus test: every side project I did just for me, I never did TDD.

How many of those side projects ended up being 6 million lines of code maintained over 5 years? Because those are the kind of code bases I have in mind when I'm weigthing the pros and cons of TDD or other testing practices. When reading Uncle Bob and others I have always got the feeling that the "goal" of the practices described is to have systems that can be maintained and extended for years by different people and…

How many side projects end up being 6 million lines of code?

How many projects at all end up that big?

How many of those end up falling under their own weight?

How many of those failures are attributable to lack of TDD?

How many of the succeeding ones succeeded on account of TDD? Or in spite of TDD?

All I've seen so far is anecdotal evidence, which is no evidence at all.

Re: Giving up on test-first development

#146

Post by jerf » Fri, Mar 18, 2016, 5:18 PM UTC

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.

Re: Giving up on test-first development

#147

Post by edwinnathaniel » Fri, Mar 18, 2016, 5:21 PM UTC

cousin_it wrote: post #37

BonsaiDen wrote: post #20

Earlier quoted context omitted.

One good way to the limit breakage in such cases is to solely perform black box tests on the API level. In case of our Node.js based Backends we don't ever write a single classical unit test, instead we have a custom Framework built on top of Mocha which performs tests on the HTTP layer against all of our endpoints. This works remarkable well in practice and allows for large scale refactorings under the hood with lit…

Yeah, I mostly prefer end-to-end tests as well. Though to be fair, they are often slower than unit tests, because you need to start up the whole system. And they are worse at pinpointing problems, though that doesn't seem to be a big deal in practice.

> though that doesn't seem to be a big deal in practice

Gotta be careful there chief. In practice is usually refers to "your experience" (but might not be mine).

My experience is on the flip side: end-to-end tests are super slow due various reasons...

Re: Giving up on test-first development

#148

Post by Chris2048 » Fri, Mar 18, 2016, 5:22 PM UTC

penguat wrote: post #12

One of the things that people aim for in writing tests is orthogonality - different tests should not break for the same reason. This promotes the ability to refactor and change your code. I have also seen massive codebases, with masses of tests which were rarely run, and which effectively concreted the code and stopped it from changing.

But doesn't test redundancy reduce the risk of a test isn't testing the thing you thought it was?

If the same situation is tested in 2 different ways, a bug in one test might cause the test to fail to correctly handle all case, but the second test might still catch.

Maybe auto-generation of test cases would be a better technology?

Re: Giving up on test-first development

#149

Post by crdoconnor » Fri, Mar 18, 2016, 5:24 PM UTC

lfowles wrote: post #126

mbrock wrote: post #54

Earlier quoted context omitted.

I don't agree with "no sense whatsoever." Actually, TDD can be a very pleasant way to do this kind of exploratory programming, precisely because it's oriented around verifying expectations.

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.

Re: Giving up on test-first development

#150

Post by Chris2048 » Fri, Mar 18, 2016, 5:26 PM UTC

neverminder wrote: post #3

"...because I think it encourages conservatism in programming, it encourages you to make design decisions that can be tested rather than the right decisions for the program users.." - Couldn't agree more with this.

I think the tests should adapt to the design, not the design to the tests..