21 lines of business logic (including whitespace and comments)

9 lines of build config

386 lines of tests (and tests for the tests)

Ah, I see you're a man of culture (enterprise Java/Spring/Dotnet dev working in the B2B space)

If you find yourself starting to write tests for tests, it might be better to start getting into formal verification and tools like Coq instead.

It sounds like a joke but are tests for tests real?

TDD simps

@Lensflare My tests included a non-trivial dependency stub, which should be tested to ensure it stubs correctly.

I don’t think I’ll ever write tests

@Oktokolo i love coq

Lmao I told you

Large tests are usually due to hideously coupled code. What % of those test lines are due to setup?

How many conditionals are hidden in that business logic and build logic? How many things can go wrong? What's the impact of them going wrong? How easy is it to change those lines?
^ tests help break this up

If they've got tests testing test _helpers_, then they probably are trying to convert those helpers into "production code" and make the production code use the better written helpers (we're trying this now and it's making our 8 year legacy much more tolerable + test setups tiny! ✨)