Giving up on test-first development • Hacker News Board

Re: Giving up on test-first development

#121

Post by catnaroek » Fri, Mar 18, 2016, 4:00 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.

A very apt analogy for the red-green-refactor cycle. I previously called it “flailing around” [https://news.ycombinator.com/item?id=11180589], but “guardrail programming” is better and catchier.

Re: Giving up on test-first development

#122

Post by czardoz » Fri, Mar 18, 2016, 4:01 PM UTC

BonsaiDen wrote: post #20

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…

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…

This is exactly why we created Newman (https://github.com/postmanlabs/newman/). Hitting every endpoint of our API gives enormous confidence when deploying it to production.

(Disclaimer: I work on Newman as a part of my day job)

Re: Giving up on test-first development

#123

Post by tjbiddle » Fri, Mar 18, 2016, 4:04 PM UTC

TDD, for me, is great at the very start. I get the nice high-level bits done, they're clean, and they get things working perfectly from the start.

But then I want to start moving fast, trying new things, I don't know exactly how I want to go about implementing things. I end up passing on tests for a while, until I hit that next threshold - then can go back; make tests for what I wrote to catch up, and then repeat.

Re: Giving up on test-first development

#124

Post by icebraining » Fri, Mar 18, 2016, 4:11 PM UTC

spinlock wrote: post #106

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…

Of your tests break when refactoring, something is wrong. Probably, you're testing the implementation not the behavior.

The behaviour of internal components is part of the implementation of the whole application.

Re: Giving up on test-first development

#125

Post by MaulingMonkey » Fri, Mar 18, 2016, 4:15 PM UTC

maccard wrote: post #113

BonsaiDen wrote: post #52

Earlier quoted context omitted.

I in part agree with the pinpointing, though in my experience this really boils down to an issue of scope and how much of the data you want to test in each of your tests. E.g. an API returning user data, do you have one test for the whole set of data or one test per field. For our use case we have some pretty "fancy" deep-equals logic for nested structures and allow to specific fields as "to be ignored" in our test e…

Count yourself lucky that your test takes 10 seconds. A partial build on my project takes ~3 minutes to compile + link. A full build is about 3 hours for everything.

I recently cut some link times from 3 minutes to 14 seconds by switching linkers (from bfd to gold doing Android dev.)

...sadly that's still only for a single project x config x arch combination. I still need to play around with incremental linking options that appear off by default...

Re: Giving up on test-first development

#126

Post by lfowles » Fri, Mar 18, 2016, 4:20 PM UTC

mbrock wrote: post #54

crdoconnor wrote: post #39

Earlier quoted context omitted.

Some (quite a lot, actually) pieces of code are essentially experimental - e.g. trying out an API/libary and seeing what it's capable of or trying an approach to solving a particular kind of problem or even trying to see if a particular problem is solvable with a piece of code. For this kind of coding, TDD makes no sense whatsoever. The 'specs' are as fluid as the code and having confidence in the code isn't that imp…

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"

Re: Giving up on test-first development

#127

Post by icebraining » Fri, Mar 18, 2016, 4:21 PM UTC

Ygg2 wrote: post #26

mbrock wrote: post #14

Earlier quoted context omitted.

If you don't know what the code is supposed to do, how are you writing it?

Imagine you make some code that needs to comply to a law, but then the law changes. Or client decides he wants his notification in different format, look shape.

Then you change the test. They are not supposed to be immutable.

Re: Giving up on test-first development

#128

Post by endemic » Fri, Mar 18, 2016, 4:29 PM UTC

BonsaiDen wrote: post #20

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…

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…

Functional tests are the best kind of tests. While unit tests are nice sanity checks when implementing tricky methods, when the rubber hits the road, you want to know if the whole app works as you expect it to.

Re: Giving up on test-first development

#129

Post by elcapitan » Fri, Mar 18, 2016, 4:29 PM UTC

A lot of discussion around that topic seems to happen without mentioning in which context the concrete development happens. The article doesn't mention which language the author works in.

In particular the "don't want to restructure the codebase because the tests would fail, so I don't write tests anymore" is probably something that you can easily get away with the more expressive your type system is. You can make lots of heavy structural changes and refactorings and if it compiles, you're mostly fine. If you try that in a Rails project, you can basically spend five times the amount of time to just test and ensure that you catch all the subtle cases where the dynamic typing in the new code structure leads to new errors.

Re: Giving up on test-first development

#130

Post by icebraining » Fri, Mar 18, 2016, 4:32 PM UTC

barrkel wrote: post #42

etamponi wrote: post #28

The author keeps talking about a "better design" achieved when not using TDD, and he goes on saying that sometimes a good design is a design that is hard to test. These are subjective, psychological feelings that, in my experience, bring only to maintenance nightmares and impossibility of doing any kind of refactor without the fear of breaking something. TDD might be difficult to do at times, but it has a very intere…

Testable design is often a poor design, mainly because of language limitations; abstraction and scoping for tests are not necessarily the best choice for abstraction and scoping for design.

Can you give an example? I'm struggling to think of a language where that can't be worked around without bending the original code.