• Zatapatique (unregistered) 
    Assert.True(new Post().IsFrist());
  • TheCPUWizard (unregistered)
    1. That is 0% code coverage [aka tool was set up wrong!]
    2. That type of test is one valuable type in an arsenal of test types. "Design Rule Checks" [DRC] are critical to keeping things inline. For example a "get only property" design should FAIL is someone adds a getter. [note I am talking about the type of tests, not specific test example]
  • Anonymous (unregistered)

    HasDefaultConstructor would again, be caught if it were used

    ...unless it is used via Reflection/Activator.CreateInstance()

  • (nodebb)

    Did they have any tests which ensured that comments don't get executed and that write space separates keywords? No? See, it's not 100%!!

  • Sauron (unregistered)

    I hate to say this, but that codebase is still better covered than most parts of the codebase of the company where I work :D

  • Oneway (unregistered)

    A testing framework or library that would mark an entire class as covered based on the given test examples should be taken out back and shot. Twice.

  • (nodebb)

    Ah yes I'm familiar with this pattern. 100% coverage is good, hell sometimes testing "basic" things isn't awful. But you have to know that testing is meant to test functionality, not behavior.

  • Tim (unregistered)

    I don't understand how you would go about configure a testing framework to show 100% test coverage without any tests which test the code, even if you wanted to

  • (nodebb)

    This ... might be the scariest manager story I have ever seen on this site.

    If this manager believes this class of test is actually helping keep bugs at bay, and (shudder) teaching that to any green developers who find their way into his group, we are looking at a Typhoid Mary level of danger, spreading out to other shops as people leave this one.

  • (nodebb) in reply to Oneway

    A testing framework or library that would mark an entire class as covered based on the given test examples should be taken out back and shot. Twice.

    With that handy GAU-8 you keep in your back pocket.

  • Dave Aronson (github)

    And this is exactly why mutation testing is so valuable. https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS is my playlist of versions of my presentation on it, in lengths from about 22 to 69 minutes, depending how in-depth you want to go.

  • Ex-Java dev (unregistered)

    I had a feeling something was up when I saw "100% test coverage". If they told me 80%, or 93%, it would sound good, but to get 100% you are either doing weird tests which barely touch the code but actually do nothing, as described, or everything is a slog.

    A type of testing I'd like to see more is behavior testing, where you are testing the overall inputs and outputs to the program, running it through scenarios at a high if not top level. This makes the tests more durable to refactors, since you weren't testing every stupid class, which is what usually happens with unit testing.

    Never got to that golden land myself, but a man can dream.

  • (nodebb)

    When I read test coverage I always have to cringe.

    Let's take this code as an easy example:

    public int Add(int a, int b) => a + b;

    Now if we write a unit test and feed it 10 different values we end up with 100% test coverage; great right, bug free code?

    Actually, no. Not at all in fact. We tested 10 combinations out of 2^65 possible once. Spitting in an ocean has more effect than this test, in fact spitting into the black hole at the center of the galaxy would have more effect.

    So (unit) tests are useless? Yes, obviously, at least in the way a lot of people think of them (aka those that care about test coverage).

    There is two awesome use cases where tests make sense:

    1. Preventing bugs from happening again (so basically bug coverage).

    2. Implementing a highly complex especially when certain not obvious acceptance criteria are required.

    3. Force developers that start coding without having a clue what to do from actually think about where they want to go once (that's called test first, part of TTD).

    While (1) is pretty much a no brainer and by far the most valuable. A bug fix without a test that makes sure that the bug never happens again is in my opinion not a bug fix, just a delay tactic. I think everyone has already been in projects where the same bug happens over and over again.

    On the other hand (2) is pretty situational and it is more a guard rail for the developer (and future developers modifying the code) than something that will result in better code. It's a tool to avoid to fall when on uncertain ground.

    The last one (3) is something that can be used to fix a bigger issue (the guy that writes code for a week and then announces it didn't out). If there's a dev on the team that doesn't know the road when starting coding then forcing code first will only patch the issue but not fix it. But sometimes there's no other way to deal with the situation, so it's better than nothing.

  • (nodebb)

    Thought longs wrote ints. Oops. For 32 bit values it would be 2^33. But I think longs have a nice ring to it because that's when the black hole works out nicely.

  • Oracles (unregistered)
    Comment held for moderation.
  • kythyria (unregistered)
    Comment held for moderation.
  • Officer Johnny Holzkopf (unregistered) in reply to MaxiTB
    Comment held for moderation.

Leave a comment on “Perfect Test Coverage”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article