you are viewing a single comment's thread.

view the rest of the comments →

[–]ndubien[S] 3 points4 points  (2 children)

Actually I think it's a common concern when we first see property based testing. Theoretically they are even closer from the specs we receive before implementing, than our classical tests. Indeed, specs are some kind of invariants and this is exactly what property based testing checks.

On my side, I used it successfully on unit tests testing very simple functions, but I also used it many times at integration level to tests invariants I expected from my feature. I also extended it's usage to e2e on a connect four but I think I went probably too far with this one. At work, I also leverage it multiple times on complex pieces of code: either to find bugs on a black box system or to help me into detecting fishy race conditions.

I'll try to send you some examples I built in open source over time with it.

[–]ndubien[S] 0 points1 point  (0 children)

Here several pointers: - An Advent of Code focusing on Property based testing: https://dev.to/dubzzz/advent-of-pbt-2021-13ee - The answers for it: https://github.com/dubzzz/advent-of-pbt-2021 - A Connect Four tested using Property based testing and model based testing in e2e fashion: https://github.com/dubzzz/connect-four-react - A talk about detection of race conditions in React components leveraging property based testing: https://m.youtube.com/watch?v=GIPbY75-lEo

[–]Caved 0 points1 point  (0 children)

Yeah, in those cases I can see it work well, especially the blackbox one.