![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
test-driven development and not
Apr. 5th, 2007 11:23 amYesterday I wrote in a maillist that I have not used a debugger in a year or so. A colleague asked me whether I was joking. No, I was not. I use unittest.
Imagine you are a mathematician. And you are supposed to solve a problem. So you propose a solution. Document it. And then you start formulating the problem, and see whether the solution matches the problem you formalize. Maybe it does, maybe it does not. Can you imagine this? Then, iteratively, you either "improve" the solution, or change the problem to match the solution.
On the other hand, imagine a world where you can first formalize your problem, in unittests, and then try to find a solution. In most cases, the search for the solution can be automated, using, say, resolution method.
In most cases, once you can formalize the problem, you do not need to formalize the solution. :)
Imagine you are a mathematician. And you are supposed to solve a problem. So you propose a solution. Document it. And then you start formulating the problem, and see whether the solution matches the problem you formalize. Maybe it does, maybe it does not. Can you imagine this? Then, iteratively, you either "improve" the solution, or change the problem to match the solution.
On the other hand, imagine a world where you can first formalize your problem, in unittests, and then try to find a solution. In most cases, the search for the solution can be automated, using, say, resolution method.
In most cases, once you can formalize the problem, you do not need to formalize the solution. :)
