• LZ79LRU (unregistered)

    And I must scream.

  • Ginssuart (unregistered)

    Once upon a time, even this solution failed because the integer overflowed.

  • Officer Johnny Holzkopf (unregistered)

    Why not simply take the code to test and put it into a giant comment, or, if comments "don't count", put them into a huge inline document / string, and then prefix it with some trivial tests that will always succeed? This way, you can get MORE THAN 100 % TEST COVERAGE, and you can automate that process as part of any code check-in! Metrics...

  • Martijn Otto (unregistered)

    With this technique, we can also easily exceed 100% test coverage. I'm aiming for 2000% coverage in my new projects. I urge everyone to strive for higher coverages as well.

  • Chad (unregistered)

    Ayys please visit, I wont tell anyone.

  • Rob (unregistered)

    Since this appears to be Java, they should have just use JaCoCo. That's easy enough to setup.

  • (nodebb)

    That's not how code coverage works or what it means. Code coverage is just the percentage of execution branches tested by automated tests. Rebranding definitions to solve a problem is as silly as it was that AI was rebranded AGI cause funding dried up on real AI research due to lack of progress. By the modern definition every program with a single execution branch is AI.

  • (nodebb)

    just count how many lines are in your tests and how many lines are in your code, and make sure that your tests make up 75% of the total codebase.

    So the testing code is considered part of the codebase? And 75% of the total code needs to be testing code? That's a 3:1 ratio of testing code to everything else! Given a requirement like that, our anonymous hero has done pretty much the only sane thing they could do.

  • Michael R (unregistered)

    Of course everyone knows it should have been ++i to get some more performance out if it.

  • (nodebb)

    BTW you should not ever show internal development metrics to management. They are clueless, all they care about is number going up and when it doesn't go up fast enough they panic. Code coverage is a prime example of this, there are tons of legitimate reasons why it makes sense to not to have high code coverage, the simplest one which is valid for every language is diminishing results. The amount of test means they need to be maintained, so they drive costs up in a big way and make changes way more expensive. So all you get for showing managers stuff like code coverage is them in return complaining how expensive everything is after they stopped complaining about code coverage.

    There is a reason why kitchens in restaurants are off limit to customers, so what a dev team does should also be off limit to stake holders.

  • (nodebb) in reply to LZ79LRU

    And I must scream.

    Here, have a mouth, Ted.

  • ichbinkeinroboter (unregistered) in reply to jkshapiro

    Actually, a 3 or 4:1 ratio of test code to code is pretty much what I have found you end up with, for decent testing. At least in .Net and nodejs

  • Mike5 (unregistered)

    This is brillant!

  • (nodebb)

    In C#, if you are down on code coverage, just ignore the untested code with [ExcludeFromCodeCoverage] on the class or method!

  • Michel R. (unregistered)

    Reminds me a bit of a project several years ago where my supervisor was making major changes to business objects and got tired of unit tests not passing and didn't feel like maintaining them, so he commented out all the unit tests. "What? They pass now..." is what he said. I have a palm imprinted on my forehead.

  • (nodebb)

    This code is very very very very very very very very very very very very very very very very very very very very very very ... [repeat 35,990 times] very good.

  • Dave Aronson (github) in reply to MaxiTB

    Code coverage is just the percentage of execution branches run by automated tests.

    There, fixed it for ya. ;-)

    Just because some test ran it, doesn't mean it was tested. For a trivial example, think about tests with no assertions; at best, that "asserts" that the code doesn't throw an uncaught error.

    Fortunately there's a fairly easy way to prove that the code isn't really tested: Mutation Testing! For a deeper explanation, pick any of these versions of my presentation on it, ranging from 21 to 68 minutes: https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS

  • (nodebb)

    Apex (Salesforce programming language) requires 75% code coverage before it can be deployed to a production instance. The Salesforce sales person probably mentioned that number and management ran with it. Since the sample code is clearly not Apex (probably an app running against the Salesforce API?) , it does not have to adhere to Salesforce's mandatory 75%.

  • (nodebb)

    Especially I like unit tests that just call the method; no input->output param validation; that almost look like legit, and even invoke some code branches, but never test anything.

  • Ghost Engineer 🚂👻 (unregistered)

    One does not "work with" Salesforce. One succumbs.

  • Faroguy (unregistered) in reply to Ginssuart

    Just make every other line i--; and problem solved!

  • Dovregubben (unregistered) in reply to MaxiTB

    Code coverage is just the percentage of execution branches tested by automated test

    Code coverage doesn't care if you test a branch or not, merely that it is executed.

  • Black Mantha (unregistered)

    A perfect example of Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."

  • Vera (unregistered) in reply to Ginssuart

    So to solve that problem, our enterprising developer changed every even i++; into an i--;.

  • Sami (unregistered) in reply to Vera

    Replacing all lines with i+=0; would be even easier.

Leave a comment on “Enterprise Code Coverage”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article