TIL that some fuzzers use code coverage metrics to drive their strategies. That's really clever! If some input can hit a line that was not previously being executed, chances are variations on it may hit more lines that haven't been covered yet.
-
Show this thread
-
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.
1 reply 0 retweets 4 likesShow 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.
1 reply 0 retweets 5 likesShow 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
2 replies 0 retweets 1 likeShow 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.
1 reply 0 retweets 1 likeShow this thread -
Replying to @yoshuawuyts
Isn't this something rust-analyzer is meant to be good at?
1 reply 0 retweets 2 likes
I think it's a bit different. RA only does static analysis of Rust code — parses, links, borrow checks, etc. Miri is a full-blown interpreter. It runs Rust code in a VM and can instrument it as it's being executed. Which seems excellent to check coverage and mess with the AST.
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.