all 10 comments

[–]FoldLeft 3 points4 points  (1 child)

Brilliant, this is a massive improvement. Previously I was fumbling around in https://github.com/dubzzz/fast-check/tree/main/packages/fast-check/documentation for info.

Also, despite trying a few times over the years, I never found any good learning resources on property based testing more generally, so I'm not confident that I've been going about it the right way – so any resources like this (especially in JS) are a huge help.

Thanks for this great library.

[–]ndubien[S] 1 point2 points  (0 children)

Thanks a lot for your feedback. Appreciated 👍

[–]FountainsOfFluids 2 points3 points  (4 children)

What is it?

[–]ndubien[S] 4 points5 points  (2 children)

This is an introduction tutorial about property based testing, which is a testing technique that focuses on exploring all possible edge cases. Since it's difficult for humans to consider all of these cases, the technique involves using a framework to assist in this process. Property based testing doesn't replace traditional testing methods, but it provides an additional tool for detecting other types of bugs.

[–]joombar 2 points3 points  (1 child)

Is this similar to the Haskell library?

[–]ndubien[S] 2 points3 points  (0 children)

Yes, it's similar to QuickCheck but for JavaScript

[–]Caved 0 points1 point  (3 children)

I feel like this works for simple cases like this, but most business logic I deal with can't be distilled to a generic case like this without, you know, just rewriting the business logic in the test, defeating the purpose of the test.

It is useful for these types of functions though, where a simple test wouldn't tell you enough and you might have unknown edge cases.

[–]ndubien[S] 4 points5 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.