While I agree with the idea that high coverage is a weak metric, this article still presents a straw man of testing.
The code was being written without proper test-first development. The test naming was also poor - we know it's a test, it doesn't need to be called "testX".
Before adding mutation testing, we need to use TDD correctly. This means two things:
1. Red, Green Refactor
2. Triangulation - adding multiple use cases to the tests so that the code can't work by accident
If we do those things, only writing any line of production code to satisfy tests, then we'll get 100% code coverage as a bi-product. Moreover, wherever there's NOT coverage, we most likely have an unexpected bug in our code or tests.
That said, mutation testing can prove other stuff. I'm yet to find a good tool for doing it at scale.
Isn't that a bad unit test ? it doesn't assert anything. From my understanding, it will pass on any function that accepts two parameters ?
While I agree with the idea that high coverage is a weak metric, this article still presents a straw man of testing.
The code was being written without proper test-first development. The test naming was also poor - we know it's a test, it doesn't need to be called "testX".
Before adding mutation testing, we need to use TDD correctly. This means two things:
1. Red, Green Refactor
2. Triangulation - adding multiple use cases to the tests so that the code can't work by accident
If we do those things, only writing any line of production code to satisfy tests, then we'll get 100% code coverage as a bi-product. Moreover, wherever there's NOT coverage, we most likely have an unexpected bug in our code or tests.
That said, mutation testing can prove other stuff. I'm yet to find a good tool for doing it at scale.