Unit Testing is Customer-Centric
If you hear someone say, “There are many ways to test software,” it's true enough, but there's an excellent chance that most engineers and managers will disagree with whatever is coming next.
Let me start with a story. I once jumped in to help out a team with some unit tests that were difficult to maintain. The code under test was integrating with a third-party library that shall remain nameless for reasons that will become obvious.
At first glance, I thought it would be relatively straightforward to offer the team some tips that would allow them to dramatically improve these test cases — more strategic use of mocks and stubs, avoiding overspecificaion in a couple of places, adjusting some of the verification.
I grabbed the source code and went to work on some exemplar test cases. And I quickly started running into roadblocks caused by the design of the third-party library. It had sprawling large interfaces, extremely complex interactions, and no accessible concrete classes to leverage. Almost impossible to create decent test doubles for, and very challenging to just wrap the whole package.
I decided to go to the library's GitHub repo to look for some inspiration on how to proceed. But none was to be found, because the maintainers almost exclusively write integration tests and indeed highly discourage contributors from submitting any. And reading between the lines in the doc it's clear they're tired of answering questions about this.
I see no evidence that this project has glaring quality problems. In fact I suspect it's quite stable. If you're just building software for your own use, maybe that's the end of the story.
But this project is a server with a complex plugin framework that other developers (their customers) need to integrate with. And here's where I take a bit of an issue with the unit-test-light approach.
If your software is built to be used by other developers, you can bet that they will want to write unit tests for the integration. In fact, they may be required to write unit tests by their management.
And if you don't write unit tests yourself, it shows up in your design in ways that make it hard for others to unit test.
You might not believe in unit tests, but for the sake of your customers, you need to consider writing them to produce a testable product.