I use REPLs in ways that are similar to yours, but 1) you have several tricks that are new to me, and 2) you've been able to put into words many ideas that I haven't!
This is cool, I'm going to start trying it. I noticed elixir's doctests a few weeks ago and it seems like a partially related idea. It's not quite the same thing but I could see a formalization like them being the "other half" of the blog post's approach for a team.
This is great, especially the more graphic tests, and timely as I'm enjoying learning Janet.
This works for regression tests, and documentation, but not so much for something like TDD, where the test is more like (or should be) a specification for the program you are about to write.
Mutation testing is where you make changes to your code's logic as a way to ensure that you have good test coverage for that bit of logic. Mutation testing is helpful with any kind of tests -- assertions, snapshots, whatever -- as a way to check that your tests are actually able to catch interesting bugs, but the idea is orthogonal to this workflow.
Hmm, I like mutation testing, and have found it very useful, but I don't know if it feels any different with this technique as it does with traditional assertion tests. Perhaps one difference is that, when you find a hole in your test coverage, it's easier to fill it in when tests are easier to write.
One thing that is a little different is that this type of testing makes it easier to write "counterfactual" tests, which are sort of similar: you observe the behavior of a function with input A, and then you make an interesting tweak to the input to get input B, and you can see how the output changes (you can even print the diff between the two outputs in your test). This is useful for ensuring that a test is actually testing exactly the thing that you want it to test -- if you have a test that "X fails validation when Y is Z," you can ensure that the only difference between a failing and a passing X is the value of Y, whereas if you only test that "X with Y=Z fails," you won't be totally confident that the failure is due to Y or due to some other newly introduced E. I think that the ability to print diffs between inputs and outputs makes this kind of REPL test a lot easier to read and write in this case.
I use REPLs in ways that are similar to yours, but 1) you have several tricks that are new to me, and 2) you've been able to put into words many ideas that I haven't!
My way is here,
http://anggtwu.net/eepitch.html
and I'm certainly going to cite you in my presentation in the next EmacsConf! =)