It's not a hack to satisfy known requirements

IMHO sperating data formats and functions works decently enough, interface/protocol/duck typing are more elegant than OO classes.

As a real world image, a barcode scanner could be applied to anything that has a barcode, regardless of what that thing is. And I'd wager 99% of what we're trying to do fits that mold. When authentifying a user, the things that matter will be wether it's a legitimate call, and whether the user is valid. Forcing that logic I to classes or filtering by use type quicky becomes noise IMHO.

It's also static, so your types declarations will replace tests.

But it's extremely inexpressive, so you can declare very few properties, and so it will replace very few tests.

And it's inflexible, so it will get on your way all the time while you program.

Anyway, I can almost guarantee you the GP wasn't talking about Java.

Obviously not every function should be -- many are so obvious and straightforward that there's nothing to test -- but every function that does anything vaguely "algorithmic" should be. Unit testing is really important for catching logic errors.

> Instead, write higher level tests close to the client/user facing behaviour that actually give you protection against breaking things unintentionally

Yes, these are good. But they're a different kind of test. There are tests for correctness, and tests that the program runs. You need both.

In fact, sometimes you even need to split up functions smaller than they otherwise would be, just so you can test an inner logic portion independently.

Yeah, no. Every time I saw code written by someone who attempted to avoid OOP it ended up with passing a huge 'context' parameter to most functions, effectively reinventing Python's OOP but worse.

Use pure functions as the starting point, but when you find yourself start passing complex structure around (any abstract word in parameter names, like 'context', 'data', 'fields' is a sign for that) just use OOP.

If it's a dynamically typed language and you want to be sure that your method throws an error on invalid types (rather than, say, treating the string "yes" as a boolean with a value of true), then unit tests are a good use for this.

I would argue that failing fast (for cases like that, where an input "could" be treated as the type you want, but almost certainly the caller is doing something wrong) is a positive thing.