That's a good question. There are different ways:
- Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found by that method, that have been missed by very formal verification processes).
- Don't call it done until you haven't proven to yourself that the code has no bugs. This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code. Often assertions are involved (which all have to be proved).
> Play around with the program intelignetly and observe no bugs
What if the computer encoded your knowledge?
> Don't call it done until you haven't proven to yourself that the code has no bugs.
What happens when the software changes? Do you repeat every single desk-checking exercise to ensure nothing has broken?
Do you even remember every click, every experimental input?
Can you prove that you do?
> This is an informal process of self-code-review but which involves quite rigorous thinking about the behavior of the code.
I trust that smarter developers than me are smarter developers than me.
But I am dumb. I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct.
But my mental simulation is frequently wrong. So I wrap myself in explicit statements of what I think the code does. Then I make those explicit statements executable. And then I run them frequently.
And frequently, I realise again that I am dumb and I should leave the flawless coding to others.
> Do you even remember every click, every experimental input?
> Can you prove that you do?
I agree some tests are a good idea depending on the project. Doesn't mean I have to like writing them!
> I assume that the code is smart and that my mental simulation of the code, which my brain helpfully and invisibly patches on the fly, is correct.
I try not to assume things until I've constructed associated proofs in my mind (and sometimes written them into comments). In fact keeping in mind what you've established (proven) and what not is a very important thing. Most of the bugs I've done are because I've simply forgotten to think about / prove something.
It's a completely different way of programming!
> Then I make those explicit statements executable. And then I run them frequently.
But I prefer to write down these explicit statements in the code itself, often as assertions. I can then prove them right on the spot!
You know, I used to be like that. Then I had the revelation that in the time it took to click test something 4 or 5 times I could write test code that could click test in less than 100ms forever.
> Play around with the program intelignetly and observe no bugs
That's the most sophomore thing I have read in a long time!!!
Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the office.
BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.
Right. In large projects some kind of automated tests are indeed useful. But they should not be a substitute for writing working code in the first place, just as an extra level of quality assurance.
Well, I haven't claimed to be able to to that, but to write mostly bugless code :) Though, writing insightful comments in the code helps. If anyone has doubt, you explain in a friendly way why they're wrong (if they are). Though, not all reviewers will study the code suffciently to find possible bugs, and also many findings are not the right/wrong kind but more about style/architecture.
Since you're actually writing tests (you say you're doing checks, which are effectively tests.) Why not just add them to a test suite?
You win twice, or more.
You get proof of the assertions you're making to your peers, you get regression tests to cover your code when it's being refactored, you also get to strongly document the intent of your code so that others can know it deeply, relatively quickly.
See devs like yourself who claim they aren't writing tests, but in essence they are, the only difference is they're not persisting their tests, and losing their value beyond initial validation of the correctness of the code.