3 ms·
> What should I (we?) be building on top of Go's fuzzer to make it easier to construct property-based tests? What's the intent behind building on top of Go's f
by randomdata 2y ago
> What should I (we?) be building on top of Go's fuzzer to make it easier to construct property-based tests?
What's the intent behind building on top of Go's fuzzer as opposed to an approach like testing/quick takes?
- ncruces 2y agoThe testing/quick package is frozen and is not accepting new features. Also: https://news.ycombinator.com/item?id=30385195 https://news.ycombinator.com/item?id=30385195 But, it occurs to me I could try and build on the same API, and compare them for effectiveness.
- randomdata 2y ago> The testing/quick package is frozen and is not accepting new features. Indeed. And respect to software that knows when it is complete, but is there some relevance to this here? > Also: https://news.ycombinator.com/item?id=30385195 https://news.ycombinator.com/item?id=30385195 While the distinction between fuzzing and PBT is, er, fuzzy, what is unquestionable is that PBT is not meant to be coverage driven. It is a means to document behaviour for other developers in a way that is, in some cases, more descriptive than providing a fixed set of examples or other "traditional" ways of providing such documentation. Seeking coverage and "interesting" cases, rather than providing documentation, is decidedly the role of fuzzing.