Hacker News Reader

Comment by jgoodhcg | Hacker News Reader

I work with clojure and test driven development is not nearly as productive as repl driven development imo.

My main problem is with the “driven” part of “test driven”. I’m fine with aiming for pervasive coverage etc., but I disagree that tests are this amazing software design tool that the test-driven ethos seems to put forth. There’s something off in the cart vs. horse equation with that.

I also work in a REPL. For me, design usually starts well before code. Then the REPL will take me towards defining behavior via understanding and exploring particulars around a solution or set of alternative solutions. Then as some final step, I will assert that it does what it should do, and guard against possible future changes violating some assumption.

There's a place for both even with a REPL I think. Sometimes when I'm tracking a bug down or writing a new function against an old one, I find that I'm writing little one-off functions or worse, replicating a function body line by line in a let block to simulate arguments. Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed. I literally got as far as opening another file to stow these little utilities before I realized I had reinvented bargain-bin testing.

My dream is still to come up with some ergonomic way of blending the two. I want to have tests written, but swap out the thing they test live in the REPL. Or register new one-off tests from the REPL for things I don't think will be useful once things are set in stone. I've heard one of the several billion testing frameworks for common lisp does something like this, but I haven't checked it out yet.

I almost always do my repl work in a source code file. That way I never lose it when the repl closes and I can copy it into a test when I know what’s going on.

[see cousin comment for my admission of stupidity]

> Once I opened up a project and realized I wanted one of them, but it was lost when the REPL closed.

You don't type directly in the REPL most of the time. Send lines and functions to it instead.

Ohhh, I wondered why people were so hyped about that! In my head I rounded it off to not wanting to recompile the whole file- I should have realized how dumb that was. This actually makes a lot of sense. When I helped a friend set up Calva, a part of me was really just assuming it was misconfigured- but no, it's designed to facilitate this kind of editing.

Though, I must ask, is it really that much better? I do keep functions around if I think I'll have a use for them again- the vast vast majority really are one-offs. Plus, most of my REPL usage is iterating on an expression. Obviously it's handy to edit it in place, but it's nice having multiple versions, even multiple trees, without having to relocate a cursor or undo unrelated changes.

> Though, I must ask, is it really that much better?

Yes, it is.

> Obviously it's handy to edit it in place, but it's nice having multiple versions, even multiple trees, without having to relocate a cursor or undo unrelated changes.

You can do both.

Depends on what you mean be effective. TDD is great if you want to be sure you don’t break things in the future. Repl seems better for getting the next thing working right now.

The repl is great for understanding something quickly and easily. It works for big new parts of the code base and small things that you just need to be reminded about. The nice thing is, if you save your repl output, you can really easily create tests from it.

I'm often wondering how to couple both. Explore freely, extract more invariants and constraints as types/tests. Iterate.

Saving repl output is a great way to make tests. It’s often the stuff that is confusing and likely to change that you exercise in that space so if you take what you find from there and make a test out of it someone will likely benefit later.

I'll have to agree here, with the caveat that this applies to functional code.

For side-effect heavy code, a repl is not nearly as productive as good tests and a debugger.

(What is interesting is that people tend not to test or check manually their code's side effects, so a repl is the best option for almost all the debugging that people actually do.)

I worked in Kotlin and Java for awhile and the closest thing I had to a repl was stopping the debugger and running arbitrary single lines of code in the context I paused. It was awful compared to the clojure repl.

I think that is the reason jupyter is as popular as it is.

Reply on news.ycombinator.com