Acceptance, end to end, integration tests whatever the fuck you call them.

Any tips on learning how to write them and doing it well? Always been tripped up in the past trying to set up databases and other bullshit so it never seemed worth the trouble since I'm so unskilled.

Well, they are kind of different things, but let's see...

Acceptance tests are, IMO, more of a dev-customer thing rather than software. They measure whether you achieve a desired threshold of whatever, which may be quantifiable and thus automated, or it may not (design, UX, etc).

You usually deal with changes in acceptance criteria through A/B testing and analytics.

End-to-end require setting up your whole infrastructure. While things like docker and such can make this trivial, they don't necessarily replicate real conditions (such as cloud deployments).

These generally require good DevOps knowledge to ensure proper setup and teardown of the infra fixture.

Also need to pay attention to the execution strategy of your test runner, or be extra explicit with preconditions to ensure you don't get inconsistent state midway from some other unrelated test.

Integrations are easier.

If you have a well defined API for your component...

... Be it an actual web API, a public interface of a class or some other mechanism, you just list each entry point (endpoint, method, etc), and for each, prepare a set of inputs, both valid and invalid, and then *DON'T LOOK AT YOUR IMPLEMENTATION*.

You only care about whether you get the output your API says you should get for that input. If not, that's a fail.

Of course, this all means that you have a written or otherwise specified API set up before implementing.

If your spec is what you implement, you can't really test.

Anything apart from integration should be tested with so called “mocks”. Classes which mimick behaviour of the real dependency. I’d be surprised if your language doesnt have a package which does exactly that. One thing my father, a herald of the golden age of software engineering,said was that databases are actually third party dependencies, which the vendor is responsible to test by themselves. What matters is whether what you wrote gets out in the expected format, and whether your application can deal with data returned from the database in the right format, and the wrong format. This gave me buddha level enlightenment

Additionally, to prove to yourself that your tests cover as many cases as possible you can use mathematical induction . Take an object n, prove that n=k, then prove that n+1=k. Then there would be stress testing i guess, of which the implementation depe ds on your architecture. Postman offers something real nice for that, whwre you can let 10,100,1000 emulated users run a train on your endpoints concurrently