Hi David.
I can totally feel your testing/mocking pain.
I think a code coverage of 100% is not practical at all.
Sometimes tests are added only to ensure the code is covered, instead of actually being a useful test.
That is exactly my biggest problem with it. Sometimes even the project template you are using comes with hundreds of lines of code. In my opinion, all the "plumbing code" is rarely testable in a nice and quick way.
At work, We are creating microservices on the Microsoft-Stack using .NET Core. And sometimes (in the smaller services) the auto-generated code (or the before mentioned plumbing code) makes up to 20% or more.
My rule of thumb is: Everything above 80% is pretty good.
And in the end, it's not about the code coverage, but about the confidence you gain from your tests. :-)
Thanks for the reply, getting another point of view here is interesting.
I think having high coverage is important, but yea, 100% definitely seems unnecessary.
Sometimes even the project template you are using comes with hundreds of lines of code. In my opinion, all the "plumbing code" is rarely testable in a nice and quick way.
This is actually one of the scenarios I mentioned about having tests for the sake of getting coverage. Its good to see that its a common issue here as well.
To me, a mix of 80% unit tests and some end-to-end tests for testing the flow of the application is a good compromise. Maybe its something we can try to improve on, and move away from the 100% unit test policy.
it's not about the code coverage, the confidence you gain from your tests. :-)
Exactly, I guess that's the main point. Thanks for the input!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi David.
I can totally feel your testing/mocking pain.
I think a code coverage of 100% is not practical at all.
That is exactly my biggest problem with it. Sometimes even the project template you are using comes with hundreds of lines of code. In my opinion, all the "plumbing code" is rarely testable in a nice and quick way.
At work, We are creating microservices on the Microsoft-Stack using .NET Core. And sometimes (in the smaller services) the auto-generated code (or the before mentioned plumbing code) makes up to 20% or more.
My rule of thumb is: Everything above 80% is pretty good.
And in the end, it's not about the code coverage, but about the confidence you gain from your tests. :-)
Thanks for the reply, getting another point of view here is interesting.
I think having high coverage is important, but yea, 100% definitely seems unnecessary.
This is actually one of the scenarios I mentioned about having tests for the sake of getting coverage. Its good to see that its a common issue here as well.
To me, a mix of 80% unit tests and some end-to-end tests for testing the flow of the application is a good compromise. Maybe its something we can try to improve on, and move away from the 100% unit test policy.
Exactly, I guess that's the main point. Thanks for the input!