How does your team approach unit testing?

I work for a large organisation, but a fairly new team. Our tech stack is JavaScript based (Node, Typescript, Angular, AWS Lambda). As a core principle for our team, we strive to always hit 100% unit test coverage in any project we work on.

While this is generally a great practice to follow, after doing this for multiple projects I can see some downsides to always having to hit 100%.

Eg:

• Having to fully mock certain things (Databases, AWS Services, etc...) just to hit the magic 100% number.
• Sometimes tests are added only to ensure the code is covered, instead of actually being a useful test.
• Having a 100% coverage policy takes a lot of time and effort to do, but doesn't actually ensure the app works end-to-end without also adding E2E tests.

From experience, I think a middle ground with high test coverage, but also including end-to-end testing seems like a better way to test applications (although this also has challenges).

I would be interested to hear about other options / opinions here, and if there are other means to ensure test coverage is high, but also functional.

Comments

[Lars Richter]

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. :-)

[David Daly]

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!