I disagree on multiple levels. First of all, programming is not computer science. Sure, we probably do not deserve to be called "engineers", but what we do goes in completely other direction - away from science and towards art.
Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not design your experiment to make your hypothesis come out true!
While the quote you cited is interesting, I'd treat it with a grain of salt, given that you can't prove that your solution works - and if you think you did, it usually turns out the proof itself is wrong. It happened even for formally proven algorithms.
Testing gives you increased confidence. It's a worthwhile goal. But IMO, driving your design by tests is going a bit too far, and something you don't need to do to have tests that ensure your code works.
"Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not design your experiment to make your hypothesis come out true!"
True, but I think that objection can be trivially fixed by simply... doing that. I write tests that confirm the code does what I designed, but I also write code that tries to break my design, and tests that verify that it errors as expected. I do approach it with a scientific mindset. (And I tend to consider "scientific mindset" to be the more important part of science vs. some overprivileging some checkpoint list of specific techniques, which ought to have come from the scientific mindset in the first place.)
Of course it remains true that you can't do that perfectly, but that's a null objection in the end. Nothing ever can be, but at least I try.
I can't even count how many times I've tested a code's error case, only to discover that it unexpectedly "worked". Usually that's because there's a bug and I need to fix the error case... every once in a while it turns out my code corrects my own understanding when it reveals what I thought was an error case is actually perfectly valid and sensible, though. It's important to try to break the code.
> I do approach it with a scientific mindset. (And I tend to consider "scientific mindset" to be the more important part of science vs. some overprivileging some checkpoint list of specific techniques, which ought to have come from the scientific mindset in the first place.)
True. If you just follow the checklist without following the spirit of the scientific method, you end up doing socio^H^H^H^H^Hcargo-cult science.
As for scientific mindset in programming, I think it's a very valuable thing to have on both larger scale - in various forms of testing - and smaller scale. I found that, when running your code, it's good to just ask yourself what exactly do you expect to happen beforehand, and if you see any deviation, immediately go figure it out, or at least note it down. If a program does something unexpected it means you don't understand it.
In stark contrast to what I've said: I also believe this to be true. Software development is a cross section of multiple disciplines: art and mathematics possibly being two of the largest within that cross section. Science, while a smaller component, is still present.
> You do not design your experiment to make your hypothesis come out true!
Indeed, as stated the TDD approach is strange and is only analogous to the formal scientific process.
> driving your design by tests is going a bit too far [...]
I didn't stick to formal TDD for very long for exactly that reason: it takes ages and constrains you to think about the tiny details instead of the grander design of the project. The upshot of formal TDD is that it usually results in low coupling but there are other ways to achieve that.
Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not design your experiment to make your hypothesis come out true!
While the quote you cited is interesting, I'd treat it with a grain of salt, given that you can't prove that your solution works - and if you think you did, it usually turns out the proof itself is wrong. It happened even for formally proven algorithms.
Testing gives you increased confidence. It's a worthwhile goal. But IMO, driving your design by tests is going a bit too far, and something you don't need to do to have tests that ensure your code works.