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

81–90 of 224 posts

Re: Giving up on test-first development

#81

Post by brightball »

I've often found it interesting that as the push for TDD has come to the industry, the rule that I was always taught to enforce backwards compatibility in your code seems to have fallen out of fashion.

For example, when Golang makes guarantees that new versions of the language won't break code working on old versions of the language that's backwards compatibility. These days, that has become a revolutionary feature while I always considered it to just be an expectation.

Because I make a point to maintain backwards compatibility, I tend to see very little benefit from TDD. It slows me down significantly. If I'm working on an MVC monolith however, eventually NOT having that test suite gets really scary.

Working with smaller pieces and enforcing backwards compatibility vs working with huge code bases that need a huge test suite is more desirable IMHO.

Re: Giving up on test-first development

#82

Post by sago »

atemerev wrote: post #56
sago wrote: post #46

Earlier quoted context omitted.

See my reply above. I think your view is either naive, or you understand 'implementation decision' in too narrow a way.

I understand "implementation decisions" in quite well-defined way; only functional invariants should be tested. Your example is a perfect illustration for one. Additional point is that invariant-based testing can easily be transformed into automated fuzzy tests using Quickcheck and its analogues, and this can find immense amount of otherwise hidden bugs.

> only functional invariants should be tested.

That makes no sense at all.

> Your example is a perfect illustration

I didn't give an example.

> invariant-based testing can easily be transformed into automated fuzzy tests

'fuzz' not 'fuzzy'. True, but irrelevant to the point being argued.

Re: Giving up on test-first development

#83

Post by ctlby »

stinos wrote: post #36
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…

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. Hear, hear! Exactly the same here, for the same reasons as you and the OP mention. And observed fom a distance, it's always the same universal principle: purist behaviour (in the sense of…

I deeply agree when it comes to programming, but there's plenty of room for absolutism in other areas of life. Why subordinate strong moral preferences to hazy cost-benefit analysis?

Re: Giving up on test-first development

#84

Post by tragic »

atemerev wrote: post #55
tragic wrote: post #45

Earlier quoted context omitted.

> some crazy folks are even testing getters and setters — why? Well, I can see the logic if your getters and setters are hiding more activity than simply retrieving/setting the value of a private field, which is the point of having separate getters/setters at all. If you imagine a getFullName() / setFullName(name) pair, for example, that actually reads from/writes to two different private fields for first and last na…

In such case, a correct test should focus on functional invariants, like getFullName() + " " + getLastName() equals to getName() (btw, never do that — names are much more complicated than that. In some countries, there are no first and last names at all; others use multiple name designations; some have meaningful patronyms etc.)

I agree (and implied) it was not a great design for actually dealing with names, but simply that sometimes there is more in getFoo() than "return foo". Which behaviour you may want to verify with a test.

EDIT: typo

Re: Giving up on test-first development

#85

Post by jon-wood »

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…

It encourages dependency injection, which in my experience will eventually encourage a functional programming style since there's so little barrier to it once you're doing things like injecting the current time into a method which makes use of it. Maybe I'll turn around in five year's time and regret saying this, but I've never regretted pushing a project in a functional direction.

Re: Giving up on test-first development

#86

Post by RHSeeger »

sago wrote: post #76
RHSeeger wrote: post #67

Earlier quoted context omitted.

> The only thing that matters to how software works for an end user is its boundary. You're ignoring the fact that tests aren't only to validate "end user functionality". They're also there to make life easier for the developer; to make both initial development and maintenance easier. If I need a custom sort algorithm for my product, I'm going to write unit tests for it's implementation. I'm also going write function…

> 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.

Re: Giving up on test-first development

#87

Post by PankajGhosh »

One of the points being discussed here is the impact on velocity due to tests not being functional and tests validating implementation details. This slows down refactoring or re-design exercises, which is quite inevitable in any customer driven project.

I suggest looking at BDD (http://guide.agilealliance.org/guide/bdd.html) which results in tests that validate scenarios/specification/behavior and are not coupled too closely with the implementation details.

Re: Giving up on test-first development

#88

Post by oldmanjay »

sago wrote: post #27
ncphillips wrote: post #22

Earlier quoted context omitted.

> Because you generated the code being motivated by the tests, there are a lot of unit tests that dot test functional units - tests that are essentially testing implementation decisions. I've seen this happen to myself numerous times as well, but I don't think this is good argument against TDD. If a tests fails because the implementation details change, that tells us that we wrote a bad test, not that TDD is bad. As…

> 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.

Re: Giving up on test-first development

#89

Post by mikehollinger »

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…

Agreed. I'd argue that if a large number of tests break when a "large" change occurs in an application, those tests are either testing the wrong thing, or written with bad starting assumptions. Yes, there's a transitional period where the responsibility may shift from the caller to the call-ee to take care of some resource, and yes, stuff will break, but the amount of test breakage should be proportional to the impact to the application.

I greatly-prefer the warm fuzziness of knowing that I have a large number of unit tests as a "safety net" to detect if my own thoughts on what is "correct" are in some way wrong.

Re: Giving up on test-first development

#90

Post by grokys »

ctlby wrote: post #83
stinos wrote: post #36

Earlier quoted context omitted.

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. Hear, hear! Exactly the same here, for the same reasons as you and the OP mention. And observed fom a distance, it's always the same universal principle: purist behaviour (in the sense of…

I deeply agree when it comes to programming, but there's plenty of room for absolutism in other areas of life. Why subordinate strong moral preferences to hazy cost-benefit analysis?

This is becoming very off-topic, but if absolutism doesn't apply in the highly-ordered world of programming, to me it's even less likely to apply in messy real-life.
Post reply on HN