4

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.
  • 1
    > "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.
  • 1
    idk ask AI to do it

    it can probably get it mostly right since it's pretty stupid, and as long as you walked code during the test that's code coverage, ayyo
Add Comment