Then, writing tests for the sake of code coverage, is like judging take a driving license exam and being judged on the streets you visited or how much gas you used. Tests need to be written with logic verification in mind.
I am deeply sad this article got upvoted. People should have a sense of responsibility when giving visibility to stuff like this.
I've heard the "executable documentation" line but my general impression is that people usually read the production code. They'll only look at the tests when they fail or they need to modify them.
I'm rather fond of this system, personally.
1: https://doc.rust-lang.org/book/testing.html#documentation-te...
Did you actually read it? Because what you just wrote, is almost exactly the same as what the article author wrote.
His point, as I read it, was that unit tests can have purpose when you don't blindly make them for code coverage.
His case for having unit tests was:
> Keep unit tests that test key algorithms for which there is a broad, formal, independent oracle of correctness, and for which there is ascribable business value
But I don't think he would disagree with the case of providing some "executable documentation" as well. A few lines of code that demonstrate how to use a class or library, along with expected results, is definitely valueable. And those are exactly the kind of interfaces you don't expect to change even when refactoring.