Similar to bebugging is mutation testing which is randomly mutating a program and then looking for examples which still pass tests as an indication of test coverage. Though many may be mutations that didn’t change semantics if your code is well tested.
I tried to hack some mutation testing together in a horrific way: I wrote some regexp source-code manipulation to replace all constants in the source code with variables and some code at the top to read those constants from stdin. Then run the tests and segfault if all the tests pass. Then a fuzzer like afl can be used to try to find mutations. Though these mutations would be relatively trivial (not eg swapping two dependant lines of code that lead to a rare race condition, but this is why it’s good to have a large set of different testing/debugging tools).
> there’s even an argument if it’s fuzzing if it’s random
One of the most important but oft overlooked aspects of proper fuzz testing is the corpus and mutation of the inputs from it. Detractors of fuzz testing often argue that they don’t see the value of it but they load up an empty corpus with a dumb fuzzer and wonder why they see thin to no results.
In my experience, you need to properly maintain a corpus to see the benefits of fuzz testing, and it’s often best to try starting from blank as well as from an existing corpus. For example, when fuzzing Go, I have used the AFL corpus with good results, since it comes preloaded with a bunch of error causing inputs.
https://en.wikipedia.org/wiki/Bebugging
Passed away 2018
Wiki edits - https://en.wikipedia.org/wiki/Special:Contributions/GeraldMW...
Only about a literal fingers on one hand of new things in computer science since 1980.
But I have no idea how this could work. What would you learn from a random card? How would it not just fault out at step one correctly so?
There's even an argument on "Talk" if it's Fuzzing if it's random.
It'd be interesting to know what was happening.
Where is there a punch card emulator & punch cards that we can try this on?