I would consider it a replacement for throwaway tests.

If I don't have a REPL, I often write a lot of little throwaway tests to deal with intermediate bits of the code. They end up being redundant with the real tests. They're often really bad tests, in that they're tightly coupled to implementation details. I should delete them. And I often forget to. Which creates extra maintenance burden for myself and my teammates.

If I do have a REPL, I do all of that extra intermediate verification junk in the REPL. It's often more effective, it's usually less effort, and it always reduces the volume of unnecessary brittle tests in the codebase.

Yeah I agree. It almost feels like he's making the argument in bad faith, but maybe he's actually unaware of the way in which you can back-fill tests?

It does come off very strangely dichotomic. As though REPL driven means no tests and bad practices, whereas TDD means tests and good practices?

As an idea, maybe we could do... both? Explore at the REPL, and then commit to tests and clean up once you've solidified your approach (i.e. how most Clojurists likely operate).

I think TDD purists seem to see no point in unit tests that are not written before the code. That is, if the unit tests were not used to drive the design and implementation of the code under test, they are useless. I find a lot of value in the test driven approach, but this purist view does not make sense to me. I sometimes, or often, write the code first (being able to do so in a repl in languages that support that is even better), when I find it easier to think through the problem in terms of implementation rather than expected output. Sometimes I will then comment out the code and begin writing tests and re-writing the code to pass them. I think that's what he should have done here; he could have benefited from playing around in the repl, but reduced his fear of refactoring later on by having the tests.

My REPL sessions tend to evolve into tests.

Same here. I start with something like:

  (some-expression 1 1)       ;; => expected result
  (some-expression 2 1)       ;; => expected result

Then I use a `let` to make changing the variable part easier:

  (let ((x 1))
    (some-expression x 1)) ;; => expected result
  (let ((x 2))
    (some-expression x 1)) ;; => expected result
  ;; repeat

Then I turn it into a function:

  (defun my-fun (x)
    (some-expression x 1))

And copy all my REPL experiments into the test suite:

  (test my-fun-tests
    (is (= ?? (my-fun 1)))
    (is (= ?? (my-fun 2)))
    ;; repeat
    )

Since I actually tend to use org mode for writing lisp code, most of the first two sections are actually inside a block like:

  #+BEGIN_SRC: lisp
  ...
  #+END_SRC

So I just have to edit this and turn it into the relevant test suite.

This is spot on. You need tests so that, during the next REPL session, you don't make changes that broke your old ones. I do also agree that people should try out TDD, especially if tests are fast to run. But a REPL is powerful tool that should not be avoided. There's a reason it's being bundled with the latest JDK releases and is an essential part of LISP and other modern languages.

Reading the blogpost again, I don't see him suggesting that you should replace unit tests with "REPL-driven design", he is merely suggesting replacing the TDD workflow with a RDD workflow, which you can still end up with unit tests, it's just that you don't write them first.