[hynek]

One of the reasons I wrote the linked article is that the wisdom around is quite fragmented and one (there’s always more than one) frustrating answer is good design makes software testable: “the deep synergy between testability and good design”: https://m.youtube.com/watch?v=4cVZvoFGJTU

Writing unit tests for software that is testable is easy. The hard part is to write testable software. But then there’s people who will argue that making software testable often leads to “test damage”.

As always, trade-offs & personal preference.

[btilly]

Part of the reason why it is so fragmented is that testing was pushed heavily by people who were all for more testing, while a lot of practical knowledge was locked up in the heads of people who spent more time being pragmatic and less being dogmatic. To the extent that pragmatism didn't support testing dogma, therefore, it got left in isolated pieces and didn't become part of the dialog.

If you listen to Kent Beck, Ron Jeffries, Martin Fowler and so on, you could be pardoned for the impression that unit testing is an idea invented by Kent Beck in 1997 with JUnit, that has taken the world by storm since.

That's complete and utter BS. Perl 5.0, released in 1994, came with Test.pm, which made it easy to write tests. Better yet, when you installed from CPAN it would BY DEFAULT run the unit test suite to be sure that your environment worked as expected. (This is a critical idea that I wish had been adopted by other repositories...)

This was Larry Wall encouraging people to follow the practices that he did. Perl 1.0, released in 1987, came with a unit test suite that ran by default before you installed it. In fact he knew the technique because he'd adopted it with his best known previous program, rn. And he knew to do that because the practice was already accepted.

Of course the idea was not original to him. See http://secretsofconsulting.blogspot.com/2008/12/how-we-used-... for the reminiscences of someone who was doing unit testing back in the punchcard era. He should know. He was Manager of Operating Systems Development for Project Mercury (the first NASA program to put humans in space). And THEY were doing unit testing back in the late 1950s, early 1960s.

Even he was not first. https://www.amazon.com/Digital-Computer-Programming-Daniel-M..., written in 1957, already described unit testing.

But, despite how widely known all of this was, Kent Beck reinvented it. And a dogma quickly emerged about this "new idea". Which included some good ideas and some terrible ones.

Extensive use of mocking I would consider a terrible idea. That it was terrible was obvious to me the first time I saw it. Replacing an external dependency with a stubbed out implementation is often an excellent idea. But mocking is a horrible way to write that implementation. I'd far, far rather deal with tests that create a SQLite database and test against than than something that does extensive mocking of what they think a database should do.