Giving up on test-first development • Hacker News Board

Re: Giving up on test-first development

#91

Post by schrodinger » Fri, Mar 18, 2016, 2:15 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.

I like to test the whole system via end-to-end tests, as they're the best bang for the buck. And then I'll create unit tests for more algorithmic code, like a parser, sort algorithm, shortest path calculator, financial calculations. Those also tend to require the least amount of test context setup, making them less painful to write.

Re: Giving up on test-first development

#92

Post by donatj » Fri, Mar 18, 2016, 2:18 PM UTC

I have found very little value in testing things with little or no logic in them. Getters, setters, those kinds of things and when we need to pivot they just stand in the way. I'm sure there are cases of critical development where that kind of thing is very important, but in most cases I think it's just unneeded.

Re: Giving up on test-first development

#93

Post by sago » Fri, Mar 18, 2016, 2:27 PM UTC

RHSeeger wrote: post #86

sago wrote: post #76

Earlier quoted context omitted.

> You're ignoring the fact that tests aren't only to validate "end user functionality". Erm, no, that was my entire point!

Wow... um... you're right. I was flitting around and dealing with external communication at the same time; you have my apologies. I think my points align pretty well with what you were saying instead of against it.

Thanks for the response, it's fun to read someone strongly disagreeing while saying what you think. slightly baffling, but fun ;)

Re: Giving up on test-first development

#94

Post by sago » Fri, Mar 18, 2016, 2:31 PM UTC

oldmanjay wrote: post #88

sago wrote: post #27

Earlier quoted context omitted.

> that tells us that we wrote a bad test, not that TDD is bad I strongly disagree. The only thing that matters to how software works for an end user is its boundary. You simply can't do TDD by only testing the boundary. You have to write a test before each unit of code, so you have to test those internal interfaces, the way units of code work. But that is exactly the stuff that should be allowed to change. It's a mis…

I have used TDD to construct many production systems. Your lack of imagination is not a particularly compelling basis for an argument.

You're disagreeing with my 'I can't imagine'? So you're saying you've built non-toy systems with TDD where you've never tested anything but the user-facing behavior of the system?

I'd be interested in knowing how, and what kind of thing you build. I can almost imagine it for an API or framework, where almost every implementation choice is on the boundary. But even then, you have to test private functions to do TDD, surely.

I work on real time stuff, and in that stuff, the user-facing functionality is hard to test, and usually not tested in a TDD kind of way. The TDD stuff is all internal.

Re: Giving up on test-first development

#95

Post by jon-wood » Fri, Mar 18, 2016, 2:37 PM UTC

zimpenfish wrote: post #49

jon-wood wrote: post #15

Over the years I've gone from writing no tests at all, to being a die hard TDD purist, and then out the other side to writing some things with tests first, others with tests after writing the code, and some without any tests at all. In some situations I have clear view of what I need to build, and how that should work. TDD is great in that case - write a test for the expected behaviour, make it pass, refactor, rinse…

> you take the bad data that caused the bug, reduce it down to a test case That's not really TDD anymore though - post-hoc testing of bad data is always going to be orders of magnitude easier because you have the bad data and you know what broke.

Think of it as TDD on the bug fix.

Re: Giving up on test-first development

#96

Post by tragic » Fri, Mar 18, 2016, 2:42 PM UTC

andrewclunn wrote: post #25

I recall a situation where a manager was pushing for TFD in an Agile environment. What a nightmare, the two just don't mix. The biggest issue isn't the approach itself, but when it hits Buzzword level with the managers who have no idea how development really works.

This is a weird argument, since both (Agile & TDD) were codified by basically the same people, or at least two sets of people with a big old overlap.

Re: Giving up on test-first development

#97

Post by enraged_camel » Fri, Mar 18, 2016, 2:44 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…

Yep. In other words, test the result, not the implementation.

Re: Giving up on test-first development

#98

Post by sitruc » Fri, Mar 18, 2016, 2:48 PM UTC

Isn't the point of TDD to create cleaner code that is robust enough for it's purpose? When the author says he is "more conservative" when using TDD; that seems to confirm that he is doing what works best rather than some kluge. Isn't that the point? Many comments have the theme of I loved TDD and then I stopped doing it when I didn't have to. That may have to with experience in the domain. TDD helps newbs (like me) cut down on mistakes while seasoned vets are able to work with more freedom.

Re: Giving up on test-first development

#99

Post by catnaroek » Fri, Mar 18, 2016, 2:54 PM UTC

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…

> Under these conditions, large scale refactorings or framework upgrades can cause massive test failures

An even bigger problem is that large scale refactorings can result in the tests themselves no longer being correct (which isn't the same thing as “not passing”), if you test at too fine a level of granularity. However, when you wrote these tests, you couldn't have possibly foreseen a large scale refactoring 18 months into the future, so how do you tell in advance what the right level of granularity for your tests is?

Re: Giving up on test-first development

#100

Post by kazagistar » Fri, Mar 18, 2016, 2:54 PM UTC

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…

When tests function as a type system as well, this is true. Buy a good type system will guide refactoring and a good module system and IDE and will guaretee isolation .