In my experience, any complex and widely used library is dead in the water without unit tests - if you make a change, you WILL break some use case, ending up in an endless cycle of fixing your changes based on user feedback, and souring your users on your library, who will refuse to update.

If you don't believe this, just write some (good) unit tests, then make the change - it's very very likely they will catch some weird corner case you've forgotten even existed.

I don't doubt the usefulness of unit tests.

I find it makes programming so much more enjoyable both in an immediate gratification and long term way.

More green checks = more dopamine Higher quality code = long term satisfaction.

But there's nothing long term about unit tests, they only verify a particular version of the code and must be tweaked whenever that code is changed to return different results. The "happy green checks" that really help in the long term are comprehensive type checks, reflecting a reasonably stable underlying design.

I don't understand.

Code does things, tests verify that it does the things I thought it did. Getting a bit of validation makes me feel good while working.

If it now needs to do completely different things then it needs different tests.

Also, if you are making huge changes to tests whenever you change a single detail, that's an issue with your code, not testing in general.

Type checks are good too. Using a typed language is even better.

This reads to me as means/ends confusion. If you write your tests afterwards, to reify the implementation of the system, this is true. They may then require radical changes when the implementation changes. On the other hand, if you write your tests first to reflect business rules and requirements, then those tests will change only when the business rules and requirements change. (Which they will, and that's OK.)

I'm not an all-TDD-all-the-time type by any means. You kind of have to at least have something to start writing tests against or it'll just be compiler errors all day long. But for the projects where I've most consistently found success in building correct systems, writing tests as soon as the basic interfaces are in place has resulted in more flexible, more reliable tests that last over the long term.

As for type checks...isn't that what a compiler is for?

Don't you think that it also alienates you from the projects? Green checks are green checks anyway, you can no longer put your input into the project and the best strategy for you becomes the minimal viable effort to earn a green check.

> minimal viable effort to earn a green check

That's literally the thesis of the Kent Beck book.

I'm not some idiot copy and pasting `expect(true).toEqual(true)`

I add functionality one test at a time. I get satisfaction of knowing it works as specified in the form of an increasing count of green checks.

I don't understand why it would alienate me.

Personally, I hate any system designed to give me lots of small bits of validation. I don't want to see green check marks, just show me any errors that I need to think about.

That's literally the same thing. I write a failing test, I fix it. Those are the errors to think about and the green check marks when I don't need to think about them.

It's the opposite. One is motivation from being completionist all-green checkmarks. Where checkmarks are good. I only want to see/think about errors. I don't care if it passed 100 tests or a 1000 tests successfully.

Edit: I get that logically they are the same, but that's true of a half-empty/half-full glass. Psychologically they are different.

Most test frameworks only really show you the failing tests in any detail as the top level results.

As you say, you don't care that there are 20k passing tests. You care just care that there is 1 failure.