3 ms·

You can't do exploratory programming writing unit tests first, can you?

by ntoshev 18y ago

gruseom 18y ago
You can. In a way, writing tests first is all about exploring. You're only specifying what you're trying to achieve in the next little while. The test is a device to tell you when you've achieved it. Then you move to the next step. What you're trying to do overall still evolves. There is a tradeoff. You end up with a longer program that does the same thing - that's bad. On the other hand it works better, and you're likelier to know if you break something - that's good. People argue about whether the bad exceeds the good or vice versa, but surely that can't be answered all one way or the other. My experience is that this style of programming is well suited for the OO environments that it emerged from. OO object graphs get complex very quickly and you need a device for managing side effects (i.e. unexpected breakage). Unit tests, specifically TDD, are the best currently known device for that. But to me a better approach is to program functionally in a way that eschews (most) side effects and to test one's code by evaluating expressions in a REPL. That gives most of the benefits of unit testing in a much lighter-weight form. I still write the occasional unit test, but only in targeted places where the code has to do something tricky and I want to keep a record of good examples. All I do in that case is put the expressions I've been playing with in the REPL into a function somewhere.
akeefer 18y ago
My experience is that it's painful if you don't have any idea of what you're doing; it's not the testing itself per se but rather the fact that if you're iterating rapidly on the code your tests will need to be rewritten over and over again. Large libraries of unit tests are invaluable for catching regressions, but they tend to impose a certain amount of friction on code changes and refactorings. So personally, I tend to do TDD when I know where I'm going, but for exploratory programming I write the minimal amount of high-level tests to test things end-to-end and make sure things kind of work at all and back-fill more detailed tests once the code has settled down a bit.
bkovitz 18y ago
I'm a TDD fanatic, but I abandon unit tests when writing exploratory code. The whole point when exploring is just to try ideas and follow inspirations. Unit testing forces you to stop every couple of minutes to think things through carefully and lock in what you've got. It messes up the exploratory flow.

You can't do exploratory programming writing unit tests first, can you?

by ntoshev 18y ago

You can't do exploratory programming writing unit tests first, can you?

You can. In a way, writing tests first is all about exploring. You're only specifying what you're trying to achieve in the next little while. The test is a device to tell you when you've achieved it. Then you move to the next step. What you're trying to do overall still evolves. There is a tradeoff. You end up with a longer program that does the same thing - that's bad. On the other hand it works better, and you're likelier to know if you break something - that's good. People argue about whether the bad exceeds the good or vice versa, but surely that can't be answered all one way or the other. My experience is that this style of programming is well suited for the OO environments that it emerged from. OO object graphs get complex very quickly and you need a device for managing side effects (i.e. unexpected breakage). Unit tests, specifically TDD, are the best currently known device for that. But to me a better approach is to program functionally in a way that eschews (most) side effects and to test one's code by evaluating expressions in a REPL. That gives most of the benefits of unit testing in a much lighter-weight form. I still write the occasional unit test, but only in targeted places where the code has to do something tricky and I want to keep a record of good examples. All I do in that case is put the expressions I've been playing with in the REPL into a function somewhere.

akeefer 18y ago

My experience is that it's painful if you don't have any idea of what you're doing; it's not the testing itself per se but rather the fact that if you're iterating rapidly on the code your tests will need to be rewritten over and over again. Large libraries of unit tests are invaluable for catching regressions, but they tend to impose a certain amount of friction on code changes and refactorings. So personally, I tend to do TDD when I know where I'm going, but for exploratory programming I write the minimal amount of high-level tests to test things end-to-end and make sure things kind of work at all and back-fill more detailed tests once the code has settled down a bit.

bkovitz 18y ago

I'm a TDD fanatic, but I abandon unit tests when writing exploratory code. The whole point when exploring is just to try ideas and follow inspirations. Unit testing forces you to stop every couple of minutes to think things through carefully and lock in what you've got. It messes up the exploratory flow.