• RonSijm@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    2 months ago

    In C# I’m generally using Verify for these happyflow tests - So instead of explitly testing every individual property, you just do Verify(state); and compare the entire state against a json saved state.

    A little bit for the same reason of “testing fatigue” - having to manually rewrite assertions of a lot of tests is getting annoying. With that approach you just do a merge compare between results, accept them, and you’re done

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 months ago

      In C# I’m generally using Verify for these happyflow tests (…)

      I don’t think this is related to this topic. The problem domain cover the exact opposite of happy flow tests: it’s about maximizing edge case coverage by minimizing the amount of tests required. This has nothing to do with what invariants you’re tracking, but how many tests you are using to cover the paths you’re covering and how to tell which tests you can dump while keeping the same coverage.

  • tyler@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    This is a decent idea for certain cases, but you’ll almost always have a better time if you use property based testing, in which case you can handle all negative cases with only a few such tests.

  • nomad@infosec.pub
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    Well… This sounds like optimizing tests for coverage. Which is not a novel idea, but certainly not the worst.

    • lysdexic@programming.devOP
      link
      fedilink
      English
      arrow-up
      4
      ·
      2 months ago

      It really depends on what problem you experience the most. Automated tests do require an awful lot of maintenance, and minimizing the number of tests you need to track all the invariants you care about is something that helps everyone in the long run.