I like the underlying idea, that you reduce your testing overlap, but have four objections:
Unit tests may give you faster and more reliable feedback than running in production.
What if your code doesn’t crash, but instead corrupts things silently. Will your production code catch that before it’s too late?
Coverage isn’t the best measurement of testedness of code. But you probably don’t want to run mutation testing in production. Or do you? See point 2.
Unit tests as documentation of intent.
And then of course, manually specified unit tests are not all there is. Erlang was the second language to have a QuickCheck implementation. Will you want to have those property validations in production? It may not be efficient, and it may not even be possible, if say your inputs are generated from expected outputs.
I like the underlying idea, that you reduce your testing overlap, but have four objections:
Unit tests may give you faster and more reliable feedback than running in production.
What if your code doesn’t crash, but instead corrupts things silently. Will your production code catch that before it’s too late?
Coverage isn’t the best measurement of testedness of code. But you probably don’t want to run mutation testing in production. Or do you? See point 2.
Unit tests as documentation of intent.
And then of course, manually specified unit tests are not all there is. Erlang was the second language to have a QuickCheck implementation. Will you want to have those property validations in production? It may not be efficient, and it may not even be possible, if say your inputs are generated from expected outputs.