4 ms·

The trouble is that for the repl “test” to be reproducible, you don’t just need to store the relevant commands and result, but the full state/history of the rep

The trouble is that for the repl “test” to be reproducible, you don’t just need to store the relevant commands and result, but the full state/history of the repl. Since the point of a repl is to explore and experiment, it seems like your tests would end up with a lot of noise in them... but perhaps there are ways to get around this? I agree the concept of quickly converting repl sessions to tests is very compelling.

samatman 6y ago
yes, there's a lot to it! I store the complete repl history, complete with results and session metadata, in a database. Pruning a session's history down to only what's needed is a manual process, true, and laying the groundwork to provide that feature has been the main yak shave.
- bch 6y ago
  > ...manual process, true Before I get to my real comment, I guess a fair criticism of it would be “Well, where in the [development process] hierarchy do you actually want to live?”, which I guess is a longer discussion, but as a developer, you can’t become battle-hardened without going to battle. So we can nod to Carl Sagan[0] and say “I made this from scratch”, and know there’s value in that. At least occasionally running your REPLs by hand and taking the actual trip, instead of just wanting the destination. It may not be tenable as a full-time production development strategy, but that doesn’t mean it’s worthless. [0] https://youtu.be/7s664NsLeFM https://youtu.be/7s664NsLeFM
deleted 6y ago
[deleted]
gmfawcett 6y ago
A common approach would be that the code you're testing / playing with is defined in a file somewhere, and reloading that file resets the REPL state sufficiently to iterate on your tests. e.g. if it does rely on external state, the reload will re-initialize that state. Morally similar to the setup instructions in a unit test.

4 ms·

The trouble is that for the repl “test” to be reproducible, you don’t just need to store the relevant commands and result, but the full state/history of the rep

by danenania 6y ago

samatman 6y ago
yes, there's a lot to it! I store the complete repl history, complete with results and session metadata, in a database. Pruning a session's history down to only what's needed is a manual process, true, and laying the groundwork to provide that feature has been the main yak shave.
- bch 6y ago
  > ...manual process, true Before I get to my real comment, I guess a fair criticism of it would be “Well, where in the [development process] hierarchy do you actually want to live?”, which I guess is a longer discussion, but as a developer, you can’t become battle-hardened without going to battle. So we can nod to Carl Sagan[0] and say “I made this from scratch”, and know there’s value in that. At least occasionally running your REPLs by hand and taking the actual trip, instead of just wanting the destination. It may not be tenable as a full-time production development strategy, but that doesn’t mean it’s worthless. [0] https://youtu.be/7s664NsLeFM https://youtu.be/7s664NsLeFM
deleted 6y ago
[deleted]
gmfawcett 6y ago
A common approach would be that the code you're testing / playing with is defined in a file somewhere, and reloading that file resets the REPL state sufficiently to iterate on your tests. e.g. if it does rely on external state, the reload will re-initialize that state. Morally similar to the setup instructions in a unit test.