3 ms·

Just to be fair, I don't think many practiononers of REPL-driven design would consider it a replacement for tests. It's an alternative workflow to TDD, yes, but

Just to be fair, I don't think many practiononers of REPL-driven design would consider it a replacement for tests. It's an alternative workflow to TDD, yes, but the idea is that you still write comprehensive tests, they're just usually at a higher more system-y level than the ones you get from TDD.

ch4s3 6y ago
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?
- goostavos 6y ago
  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).
  - sanderjd 6y ago
    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.
  - kmclean 6y ago
    Yeah this is mostly how I operate when writing clojure.. development mostlty happens at the REPL and the bits that work get copied into a file somewhere and then once I have an idea how the whole system is going to work, I write an automated test for it instead of testing it manually. Tests replace manual testing in my workflow.
whateveracct 6y ago
My REPL sessions tend to evolve into tests.
- Jtsummers 6y ago
  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.
mumblemumble 6y ago
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.
leoh 6y ago
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.
capableweb 6y ago
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.

ch4s3 6y ago

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?

goostavos 6y ago
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).
- sanderjd 6y ago
  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.
- kmclean 6y ago
  Yeah this is mostly how I operate when writing clojure.. development mostlty happens at the REPL and the bits that work get copied into a file somewhere and then once I have an idea how the whole system is going to work, I write an automated test for it instead of testing it manually. Tests replace manual testing in my workflow.

whateveracct 6y ago

My REPL sessions tend to evolve into tests.

Jtsummers 6y ago
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.

mumblemumble 6y ago

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.

leoh 6y ago

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.

capableweb 6y ago

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.