3 ms·

This sounds extremely useful and touches on one of the big frustrations I have with "REPL driven development". Say what you will about TDD, but it does (often?

This sounds extremely useful and touches on one of the big frustrations I have with "REPL driven development". Say what you will about TDD, but it does (often? sometimes? depends widely on how the tests are being written) produce useful, informative and functional artifacts. If you need to know how to create some entity or how to run some process, chances are there are tests that you can refer to that will show you how things are intended to work. This shouldn't take the place of comprehensive documentation, but it's a welcome counterpart. With REPL driven development, there's nothing of the sort. If the developer has not provided documentation, you'll probably have to try to reverse engineer a given workflow based on the state of the system, which can be very problematic.

samatman 6y ago
Yep! Now imagine that you can instantly load a REPL session with complete tests, already executed, hanging out in the session history. Now you can change anything in the test and see what it does. That's the idea anyway.
gmfawcett 6y ago
> With REPL driven development, there's nothing of the sort. Wouldn't there be production code that you can read? You're already working in the codebase after all. I agree that a unit test might have a cleaner, distilled setup procedure though.
- ethagnawl 6y ago
  In the specific case I have in mind, there was a business process that involved multiple pieces of the application being used to accomplish a task (creating database entries, etc.). Prior to my inheriting the project, this had been done in an ad hoc manner using the REPL and was not documented. When I had to try to run this process myself, I had nothing to go on. This is absolutely the result of poor practices and, documentation aside, if the developers had been using tests to drive out this behavior, I'd have had a sort of playbook that I could reference.
  - gmfawcett 6y ago
    That sounds horrible! But this is an operational failure, not a development one. (Well, the one clear development gap is that nobody thought to write a script to replace all those REPL commands. There's no reason that couldn't have been done, that's not a REPL issue at all.) It's not uncommon for REPL users to write tests for their code. And nobody worth their salt would think that the REPL is a license not to document and operationalize their work properly! Your root cause seems to be some mix of developer laziness or inexperience, and poor business practice -- not really a tooling issue.

samatman 6y ago

Yep! Now imagine that you can instantly load a REPL session with complete tests, already executed, hanging out in the session history. Now you can change anything in the test and see what it does. That's the idea anyway.

gmfawcett 6y ago

> With REPL driven development, there's nothing of the sort. Wouldn't there be production code that you can read? You're already working in the codebase after all. I agree that a unit test might have a cleaner, distilled setup procedure though.

ethagnawl 6y ago
In the specific case I have in mind, there was a business process that involved multiple pieces of the application being used to accomplish a task (creating database entries, etc.). Prior to my inheriting the project, this had been done in an ad hoc manner using the REPL and was not documented. When I had to try to run this process myself, I had nothing to go on. This is absolutely the result of poor practices and, documentation aside, if the developers had been using tests to drive out this behavior, I'd have had a sort of playbook that I could reference.
- gmfawcett 6y ago
  That sounds horrible! But this is an operational failure, not a development one. (Well, the one clear development gap is that nobody thought to write a script to replace all those REPL commands. There's no reason that couldn't have been done, that's not a REPL issue at all.) It's not uncommon for REPL users to write tests for their code. And nobody worth their salt would think that the REPL is a license not to document and operationalize their work properly! Your root cause seems to be some mix of developer laziness or inexperience, and poor business practice -- not really a tooling issue.