The essential complexity of writing unit tests is in formulating your assumptions ahead of time. As you correctly point out, no tool can ever solve this. However, an accidental complexity is correctly expressing your assumptions in code. Tools such as a REPL and this library can definitely help with that.
In general, I prefer to start writing tests, just enough the tests fail but call the functionality (this makes API design flaws obvious), then actually build the functionality and, finally, make the test conditions reflect what we need.
To be honest, my development REPL logs have a lot of junk, so it would be extra work to write a clean one, and then make the right assertion (maybe I was looking for "even number" not "exactly 132"). Lisp-y REPLs are friendlier than some, but it would be cool to associate it with something like a notebook where it is easier to update imports/mocks/etc out of order. Cool idea though.
1. Unit testing is a kind of functional testing. On a unit.
2. And regression testing is rerunning your existing functional tests after, say, refactoring, to see if they pass.
Complex? Confusing? Which part of this precisely is confusing?
So if I say 'I wrote a unit test' what kind of test do you expect?
The headline says they're generating unit tests automatically.
Which means I expect that I run a command, and it plops out unit test code. automatically. without my interaction.
The article is about recording repl interactions. that's not automatic.
and really, they look like implementation details? so bad examples? I don't know scheme, so shrug
You gotta pick a better hobby.
Now, bear in mind that I say this as a passionate tester and verification enthusiast. I don’t have a better alternative, so I keep writing tests. And yes, they do catch bugs. I’m not saying they have no value. I’m saying, they always let some bugs through, I.e, they are not complete.
And that makes the cost of them very depressing. Not only cost to write, cost to continuously run.
REPL-driven development is basically test-driven development with sorter feedback cycles during active development, but the downside is you need to make an extra effort to go back and preserve the important tests for posterity. This might well reduce some of that friction.