8 ms·

Step1: Write a test. Step2, IDE: Right click + Run. Step2, CLI: $ run <test name> Bonus: The test is now part of your automated test suite, and will be ran m

Step1: Write a test. Step2, IDE: Right click + Run. Step2, CLI: $ run <test name> Bonus: The test is now part of your automated test suite, and will be ran many times to ensure things don't break.

pjmlp 5y ago
Now try to fix the code from the unit test when it breaks and redo the unit test, from the point where it broke.
- mypalmike 5y ago
  Throw a breakpoint in the unit test.
  - pjmlp 5y ago
    It won't work on the CLI version, and unless you are using an IDE with a backtracking debugging it won't help.
- lmm 5y ago
  So that you can run your unit test from some unknown state that may not even be reachable from the current text of the code, rather than running it from the start in a reproducible way? Why would that be something you want?
  - pjmlp 5y ago
    Unit testing was born in the Smalltalk community, good tooling is orthogonal to having tests.
dec0dedab0de 5y ago
What if you don't know what you want it to do yet? Maybe you have a new API or library you're working with and the documentation is lacking. Maybe you're exploring some dataset trying to figure out what kind of information can be gleaned from it. Maybe it takes 3 minutes to get it into the state where it failed, so instead of starting over every change you just want to modify the one function over and over. Doing it in a repl like jupyter has you run the actual code many times as you're writing it so ensure things don't break before you ever save the file. Of course thats not an excuse to skip tests, but if I was going to pick one, I would choose running the code as I write it, instead of testing it after the fact.
- bookofsand 5y ago
  A. Then don't submit the exploratory test in your next PR. B. Then memoize the expensive function to disk. Bonus: Can keep multiple versions on disk, thus can tweak the expensive function while having fast reloads with guaranteed correct version.

Step1: Write a test. Step2, IDE: Right click + Run. Step2, CLI: $ run <test name> Bonus: The test is now part of your automated test suite, and will be ran many times to ensure things don't break.

pjmlp 5y ago

Now try to fix the code from the unit test when it breaks and redo the unit test, from the point where it broke.

mypalmike 5y ago
Throw a breakpoint in the unit test.
- pjmlp 5y ago
  It won't work on the CLI version, and unless you are using an IDE with a backtracking debugging it won't help.
lmm 5y ago
So that you can run your unit test from some unknown state that may not even be reachable from the current text of the code, rather than running it from the start in a reproducible way? Why would that be something you want?
- pjmlp 5y ago
  Unit testing was born in the Smalltalk community, good tooling is orthogonal to having tests.

dec0dedab0de 5y ago

What if you don't know what you want it to do yet? Maybe you have a new API or library you're working with and the documentation is lacking. Maybe you're exploring some dataset trying to figure out what kind of information can be gleaned from it. Maybe it takes 3 minutes to get it into the state where it failed, so instead of starting over every change you just want to modify the one function over and over. Doing it in a repl like jupyter has you run the actual code many times as you're writing it so ensure things don't break before you ever save the file. Of course thats not an excuse to skip tests, but if I was going to pick one, I would choose running the code as I write it, instead of testing it after the fact.

bookofsand 5y ago
A. Then don't submit the exploratory test in your next PR. B. Then memoize the expensive function to disk. Bonus: Can keep multiple versions on disk, thus can tweak the expensive function while having fast reloads with guaranteed correct version.