[videogreg93]

Thank you! I feel like all of this Unit test stuff is just a case of Emperor's New Cloths: everyone writes tests, no one knows why but won't admit it. I've never never ever experienced in my life a time where a major problem was automatically found by some unit tests before it got pushed to production.

[jerf]

"I've never never ever experienced in my life a time where a major problem was automatically found by some unit tests before it got pushed to production."

Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback. I literally can't count the number of times it has popped up a bug that I wouldn't have expected because of some change.

It is that very characteristic that makes me love them so much. No matter how carefully you code you can never get away from the problem of a small change over there causing a breaking over here because of something you couldn't even have anticipated, but you don't have to wait until some large-scale QA process or even production deployment to find out; you can find out 15 seconds later, and then fix it, or realize your new change is fundamentally untenable, or any number of things. I'd say "I don't know how people develop without these things", except I do; the code bases are treated like quick-set concrete and nothing can be changed once laid down. What a stultifying way to code. I would hate to work at a job like that.

[dwaite]

> Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback.

IMHO thats the biggest problem with TDD. People often think of TDD as a set of requirements that all push for some set of benefits.

But it is really a development methodology where you as a developer heavily utilize tests to drive the development process itself. It is a mindset, not a checklist.

Perhaps easiest to explain (with an inaccurate comparison) as - it is like REPL-driven development but with persistent and sharable artifacts.

Behavioral driven development is IMHO stronger in this regards, because people tend to understand how the additional artifacts (beyond what you might see with a requirements list or use case document) are part of a methodology. People can better separate the methodology from the benefits/outcome.

[major505]

Here is the thing: Most managers want you to implement the test and the code in the same time It would take to write only the code.

The thing is, in the end most devs do shit tests becase theres no time allocated to that, and the test end up being just a number that needs to be met so the code could run to the dev ops engine and generte a new version of the software.

[naasking]

Tests typically let you write code faster because you can rely on the test suite to check most standard assumptions and inputs/outputs. Thus, you have significantly less to test as time goes on.

[jerf]

Not writing test code is faster the first day.

It's somewhat faster the second day.

It's a bit faster the third day.

It's probably net faster the fourth day, though by now you're developing noticeably more slowly.

It may still be net faster the fifth day.

It's net slower the sixth day, and the delta gets worse from that point on.

And I don't mean "per bug" on that, either. I mean, per project. By the sixth day of the project, you are net slower not writing any test code. And again let me emphasize net; by day six you are already losing overall.

Expecting test code to be written in the same amount of time as normal code is actually eminently reasonable, indeed it's the only sensible way to do it... if you do it right.

[spiddy]

That's because by definition it is not going to be "major" problem since the unit test acted as gateway before it got pushed to production, instead you'll probably be 'meh' and fix it once the unit test fails.

This reminds me the saying of a manager arguing why do we need so many SREs since the system is working fine.

[matthewfcarlson]

This is sort of why I wrote the article. Professionally, I’ve seen tests just cause tons of noise and offer little benefit. So I tried applying it to a personal project on a whim and found some unexpected benefits

[dwaite]

Test driven development on one project would often save me weeks per bug fix.

This was because it maintained an environment where I could replicate portions of the business logic (as assembled modules) outside a production environment. This made it much easier to do analysis/fuzzing of one component of the system, vs trying to replicate and do post-mortem crash analysis on the entire deployed system.

But I clarify this is TDD, not unit tests. A development methodology where unit tests are wedged in after the fact do not promote the sort of modular programming needed to be able to do this.

[nonethewiser]

I think it can be taken too far but why not have some unit tests? They are the easiest kind of test to write and the fastest to run.

Also, you dont see it because those bugs were fixed before production.

[UK-AL]

I have. A lot.

[cwilby]

Our team too, time saved is fairly quantifiable.

[disgruntledphd2]

I mean, you probably need automated CI before this becomes likely as otherwise people just forget to run the tests...

[nonethewiser]

You absolutely need that.

[cwilby]

Yes, test frequently and automatically.