Gahh, Mutagen is so cool in this regard. It randomly mutates source code operations to see if tests still pass — if they do it points to missing tests. It can do this because it operates on ASTs.
-
-
Show this thread
-
Riffing here: could see some fuzzer come along for say, HTML parsing in Rust. It could generate HTML test cases based using an AST so inputs are valid tokens. But during execution it could instrument the Rust source to try and cover as many branches as possible.
Show this thread -
Also what if we put these approaches together? What if we could use coverage information to generate inputs that haven't yet been covered by existing unit tests? Rustc has lots of "valid weird input" tests — having tools that can help expand the unit test corpus would be great
Show this thread -
Also worth noting that Miri, the Rust interpreter, exists and could probably be used for things like coverage tracking and mutating the Rust AST.
Show this thread
End of conversation
New conversation -
-
-
That's the kicker about any kind of fuzzing/properties is that you to be careful about the ranges that you are hitting as your tests may otherwise be ineffective. John Hughs (author of quickcheck and quviq) talked about this range aspect about a year agohttps://www.youtube.com/watch?v=NcJOiQlzlXQ&t=91s …
-
Also this one is really great, too! https://www.youtube.com/watch?v=zvRAyq5wj38 … Fuzzers are a bit different because you're relying on the fuzzing library to do all the mutagenic work of the corpus behind the scenes, but they can be quite clever! Generators (ought to) give you more control.
End of conversation
New conversation -
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.