Giving up on test-first development • Hacker News Board

Re: Giving up on test-first development

#101

Post by [deleted] » Fri, Mar 18, 2016, 3:00 PM UTC

mbrock wrote: post #14

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…

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

[deleted]

Re: Giving up on test-first development

#102

Post by guzmanovich » Fri, Mar 18, 2016, 3:01 PM UTC

I had the same journey as the writer, except I now have done a full circle and am back on TDD. The problem is not TDD, the problem is unit testing, mocking and TDD.

If you are able to write tests from a user story level, i.e. scenario or functional tests, where you are testing from the top down, then TDD is actually very helpful also in the sense of program design and making you think very closely on what problem you want to solve.

Re: Giving up on test-first development

#103

Post by pmarreck » Fri, Mar 18, 2016, 3:06 PM UTC

Psychologically, you become conservative to avoid breaking lots of tests.

Psychologically, the FIRST problem is that there is a distinct separation in his head between "working" code and "test" code. They are essentially married together. "Breaking tests" is simply identifying now-broken functionality that would NOT have been highlighted had he made the change WITHOUT that test coverage.

Basically, I don't understand how one could come to this conclusion unless one was 1) terrible at writing tests, 2) did too many integration tests and not enough unit tests, or 3) had the wrong frame of mind when considering test code as "distinct and separate" from the code under test.

But as I started implementing a GUI, the tests got harder to write

That is due to the architecture of the GUI, not a fault of TDD itself. As this stackoverflow says, http://stackoverflow.com/questions/382946/how-to-apply-test-..., "you don't apply TDD to the GUI, you design the GUI in such as way that there's a layer just underneath you can develop with TDD. The Gui is reduced to a trivial mapping of controls to the ViewModel, often with framework bindings, and so is ignored for TDD."

If the GUI is not architectured in a way that makes that easy, then you're going to have a bad time, admittedly. See: http://alistair.cockburn.us/Hexagonal+architecture and the Boundaries talk https://www.destroyallsoftware.com/talks/boundaries for examples of ways you can reduce I/O to an extremely thin layer that can be tested in isolation.

Re: Giving up on test-first development

#104

Post by justifier » Fri, Mar 18, 2016, 3:06 PM UTC

i used to keep track of bugs i found from creating or updating tests as a preemptive response to those who claim active testing is a waste

now i just wonder why people are so against it

i enjoy the time i spend trying to break my own code

Re: Giving up on test-first development

#105

Post by a_imho » Fri, Mar 18, 2016, 3:08 PM UTC

https://news.ycombinator.com/item?id=3033446

Re: Giving up on test-first development

#106

Post by spinlock » Fri, Mar 18, 2016, 3:12 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…

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

Re: Giving up on test-first development

#107

Post by talles » Fri, Mar 18, 2016, 3:14 PM UTC

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.

Re: Giving up on test-first development

#108

Post by mamon » Fri, Mar 18, 2016, 3:15 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…

Ruby and Javascript are dynamic languages, so you need all those tests to make up for missing compiler type checks. With staticaly typed languages like Java or Scala things are much different.

Re: Giving up on test-first development

#109

Post by ebbv » Fri, Mar 18, 2016, 3:15 PM UTC

gazrogers wrote: post #78

ebbv wrote: post #31

> Sometimes, the best design is one that’s hard to test I strongly disagree with this statement. The best design for your program is always the one that's easiest to test; the one that's modular, the one that separates out dependencies, the one where methods are as atomic as possible. If you find yourself wanting to write code that is hard to test, then you are approaching the problem (and/or the solution) the wrong…

The author's hardly a novice when it comes to software design though: http://www.amazon.co.uk/Software-Engineering-Ian-Sommerville...

I realize that, but he's still wrong on those points I addressed.

Re: Giving up on test-first development

#110

Post by quaunaut » Fri, Mar 18, 2016, 3:20 PM UTC

adrianN wrote: post #24

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…

If one test breaks you get a nice message. If 20% of your tests break because they depend on functionality that you just changed intentionally, you increased the cost of your feature a lot.

I don't really see how?

If you changed that functionality intentionally, then the other things it interacts with will require a change regardless. Furthermore, if it's that small of a change(as usually, the smallest changes are the ones that impact the most tests), it usually doesn't require any change to the test, aside from adding/subtracting a parameter or something.

Major functionality changes should carry weight. It's like saying that a motorcycle runs so much faster without a person on it- it defeats the purpose.