Title says unit tests. But to GP's point, it isn't really automatic, the developer still decides what to test. It is transforming REPL logs, not generating tests based directly on the code (which isn't useful in my experience).

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.

Unit test and regression test are not in conflict.

They are when you refer to regressions tests as unit tests.

Unit testing is "what" you test, it's your scope. And regression testing is "why" you're testing, you running tests to detect regressions.

Right, but if you're testing the 'why' and calling it a unit test... confusion ensues...

Is it that confusing that units of code are subject to change, hence subject to regressions, hence their tests are used to prevent regression?

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?

Realisticly the problem here is;

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

Your problem appears to be your entire focus is pointlessly nitpicking the meaning of everyone’s words where enough context exists to trivially disambiguate it.

You gotta pick a better hobby.

You said a unit test is 'what' you test?

So if I say 'I wrote a unit test' what kind of test do you expect?

I expect test for a unit. Honestly don’t know what your problem is.

Makes sense, but it's always good to capture the intent of the test. If it is to prevent a regression, having data about the issue that was fixed is vital.

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.