4 ms·
If your writing little functions in a REPL you get to see the results of that code immediately, in a sense, that is test-driven -- the verification aspect is pr
by olliesaunders 17y ago
If your writing little functions in a REPL you get to see the results of that code immediately, in a sense, that is test-driven -- the verification aspect is present. What isn't present is the test-first aspect that ensures your code is easily testable, which is valuable. And you don't have the test code to keep in a suite to run whenever to check for harmful synergies.
You could probably write a REPL with the appropriate commands that would build rudimentary test code from lines you executed that did what you wanted them to.
- prodigal_erik 17y agoThat's the best idea I've seen in a long time. Give an expr, get a value, and if you like it, type something meaning "add a test that evals that expr and expects the value I just saw". The only risk is convincing yourself that what you got looks right when it's actually not.
- blasdel 17y agodoctest comes with Python. You paste from REPL sessions into doccomments, and use a little utility function to automatically find/run them. It's not as useful as you'd think -- the only way to structure the tests is by the class or function the comment is on, and you have to go out of your way to avoid default __repr__ returns of the form "<object foo at 0xADDRESS>", as the expected response handling is ANAL.
- abstractbill 17y agoYou could probably write a REPL with the appropriate commands that would build rudimentary test code from lines you executed that did what you wanted them to. I did exactly this, in a previous job where we were required to unit-test a lot more than I liked. I always mess around with stuff in the REPL a lot anyway, and it was dead simple to write an Emacs command to turn my REPL sessions into unit tests.