Hacker News Reader

Comment by chii | Hacker News Reader

> These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds

i tend to disagree.

If you tried to express some thought but the compile time tests tells you you're wrong, you might actually just have an incomplete thought, or have not thought through all of the consequences of said expression.

It's basically what type-checking is in haskell - you cannot compile a program that does not type-check correctly. This forces you as a programmer, to always, and only, express complete thoughts. Incomplete, or contradictory thoughts cannot be expressed.

This should, in theory, lead to programs that are more well thought out. It also makes the program harder to write, because it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care.

View on HN

> it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care.

And this is precisely why I disagree with forcing it upon the developer at every stage of development. Generally, while in the thick of things, I just want to get things working with one part, not worry about what other parts this breaks (yet). But the pedantic "you have to fix this first" enforcement breaks my concentration because now I have to split my attention to things I don't want to even be bothered with yet. I'll get to it, but I sure as hell don't want you telling me WHEN I should.

> because now I have to split my attention to things I don't want to even be bothered with yet.

One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them.

Is that the same as saying I don't want to have to write types either? Maybe. Types are like lightweight incomplete specs.

> One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them.

Or perhaps the parts existed, were useful, did have tests, and now a new feature requires refactoring that temporarily breaks things before I finally bring the house in order again. But I don't want to throw out the tests because parts of them may still be useful.

My point is, if the code is capable of being compiled and run, who is anyone to dictate that I shouldn't be allowed to run it (even broken) during my development cycle, just for some bureaucratic "I know better than you" reason?

This is the problem I see all over - people peer out from their limited perspective, assume that they see enough, and then make excessively restrictive policy decisions about what we can and cannot do. It's hubristic and so very, very annoying to the rest of us, especially since they also have a tendency to double-down, and there seems to be no way of getting through to them.

> I don't want to even be bothered with yet

Why did you get out of your way to write tests about something that you don't want to be bothered about?

Because the test already exists as part of the solution that's worked up until now, and I don't want to modify it or any other related tests until I've finished my work to the point that I think the interface is stable enough for the tests to be updated.

Test-driven development has its uses. But it is wrong to make it mandatory. I myself run static checks/unit tests almost all of the time. Still it is useful to skip them from time to time and just run the code to see the results (make it work before you make it "right" according to some linters rules).

Reply on news.ycombinator.com