[sholladay]

This is why you should:

- Write functional tests, not unit tests

- Not use compilers or other systems that do a lot of black magic (like changing the type signature of your functions (!))

[p1necone]

I almost never write single function unit tests. There's usually some subset of the codebase that's self contained that makes sense to be the "unit" you're testing, but it's almost always a handful of functions with a clear entry point.

My general rule is to never mock or remove anything that has no side effects from the execution path of a test, even if it's some utility function that's already tested in isolation in its own test suite - trying to isolate every little bit of behaviour to be tested separately is just a bunch of extra work for questionable benefit.

I still call these tests "unit tests", and I think a lot of people do also. But there are the dogmatic people to whom only a test covering a single function with all dependencies mocked out is a true unit test.

[nzeid]

This made me laugh because I can't name a single compiler that _doesn't_ do black magic.

But I concede that a thing that coerces your functions into async without adapting the corresponding calls is hilariously broken.

[bitwize]

Absolutely write single-function unit tests, if the function has clearly defined inputs and outputs but a tricky implementation. A lot of business rules work this way, so if you have a "functional core, imperative shell" line-of-business application with unclear or changing requirements, unit tests will be your best friend for getting the details right.

But testing each class in the project with a Mockito-encrusted setup featuring cardboard bananas/gorillas/jungles—best practice in Java-land—seems tedious, and tedium is the enemy of a good testing strategy because programmers won't follow it. They'll bodge in a solution, get their teammates to lgtm it, and roll it out under the slightest bit of deadline pressure.

[actionfromafar]

It also helps to not use languages with truthy / falsey values.

[Zambyte]

I kind of like the Scheme way of doing it, which is to have a true and a false value, and everything besides false is truthy. All strings including the empty string are true, all numbers including zero are true, all lists including the empty list are true. This makes it easy to define values as false when they are expected to be set to something else later, and you can just check the value as a condition to see if it's set or not, and then you can use it directly if it is.