This isn't just a matter of "reducing boilerplate". Right now you need too much skill to write useful inputs. That skill barrier blocks a lot of people from using PBT seriously, even if it's well-suited to their problem
-
Show this thread
-
Replying to @hillelogram
I keep saying the same thing about both fuzz testing and using static analysis tools! They are awesome, but have high startup costs, high integration costs, and require expert knowledge. They need a lot more UX work to be widely usable.
1 reply 3 retweets 13 likes -
Replying to @bradlarsen @hillelogram
IMO, one thing that's easy and under-rated is writing simple scripts to fuzz things without using tools. I've walked people through doing this a few times and the reaction has been "wow, I didn't realize it was this easy to write a useful fuzzer" every time.
2 replies 5 retweets 22 likes -
I don't disagree with the above comments that existing property-based testing tools/frameworks can be pretty high overhead for people getting started, but I think people drastically overestimate the effort it takes to get started with no tooling at all.
1 reply 0 retweets 10 likes -
exactly! no need to get all fancy, just fuzz stuff. once this is a habit it's like wearing a seatbelt: if just feels wrong to stop.
1 reply 0 retweets 14 likes -
I'd be interested in a tutorial on handrolling situated fuzzers
2 replies 0 retweets 5 likes -
I wrote a series of blog posts about this a few years ago. here's one of them: https://blog.regehr.org/archives/896
2 replies 7 retweets 42 likes -
Replying to @johnregehr @hillelogram and
it's no exaggeration to say that I would never, ever trust unit tests while implementing something like a balanced tree. not mine, not anyone else's.
2 replies 3 retweets 23 likes -
Replying to @johnregehr @hillelogram and
would you trust code that's only proven to work, but not tested?
3 replies 0 retweets 3 likes -
Replying to @Gok @johnregehr and
I've heard (and can't verify that this is true) that the FDIV bug happened when Intel formally verified the SRT algorithm but failed to check that they were programming their PLAs correctly, vaguely analogous to failing to check that your compiler is producing correct object code
1 reply 0 retweets 1 like
That's interesting if true since I've probably seen the FDIV bug used as justification for formal methods in hardware a double digit number of times, but the ROI on formally verifying that vs. testing that you're writing the values you want to your PLAs seems pretty low.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.