Software Testing

225 readers

1 users here now

Spreading knowledge on software testing and the value it can provide, as well as a location to ask questions about implementations or testing strategies or frameworks

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

Ategon@programming.dev

lackthought@lemmy.sdf.org

Avoiding Test-Case Permutation Blowout (2021) (www.stevenhicks.me)

submitted 2 months ago by lysdexic@programming.dev to c/software_testing@programming.dev

5 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] RonSijm@programming.dev 2 points 2 months ago (1 children)

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.dev 3 points 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.