4
c3whittle
34d

Management has reviewed DevOps which is already being shown to customers and wants to introduce a code coverage metric to show customers how good the code is. Code coverage now has to be 80% or higher across the board, it's been decided by management, and there is no discussion on this topic. The front-end presentation layer has minimal business logic and most of the code that exists is generated objects to shift data to the backend (which in turn mostly shifts it to a 3rd party API that does a lot of the business logic). I now have to write thousands of pointless tests while also being 85% billable to the client.
I think code coverage can be used as a tool, but should not be used as a metric to promote the product.
I suggested an automated e2e test might be better placed to prove that things are working, but have been told we're not going in that direction.
I'm close to writing a code coverage test that uses reflection to touch all of the code, catch all exceptions, and return a positive result.

Comments
  • 1
    Ouch... Do everything as snapshot tests or something and have it auto update on all prs... 🙈
  • 1
    Add a smoke test that just clicks a load of random buttons and whatever to make sure it's working.
  • 2
    Meet requirements, ignore pointless expectations.
  • 2
    > "Code coverage now has to be 80% or higher across the board"

    I'm so sorry.

    If it helps (and you're using C#), you can set a directive on/in a file/class that tells the compiler to ignore that metric.
  • 0
    @jestdotty Yeah that's a good suggestion so will second it
Add Comment