Eliminate potential bugs in the program earlier in the process. i.e to avoid programming by coincidence
Anyone want to chip in ?
Design on paper first, and then convert those paper thoughts into tests. As you're writing your tests out, you'll think of edge cases and it will take a second or two to write a test header for it.
Before you have a line of code, paper and pencil are your best friends.
I will actually execute the program in most cases. Most of the development I do is in the context of a web request (server) or browser DOM (client) so running some quick snippet of code might be as simple as initiating a request from my browser to see what the server does or interacting with it in some other way which triggers the client-side stuff.
You're going to have "something you start with" (input) and "what you want it to be" (output). Understanding these things will go a long way to reason out what you need to actually do to accomplish your goal. Usually a program's "goal" is to "output the correct thing" and the programmer will have to know what "correct" is.
Certainly no formal proofs and I usually work things out "in my head", as it were, because it helps me to understand the problem that I'm working on. See also "rubber ducking" (https://en.wikipedia.org/wiki/Rubber_duck_debugging). It might help to try to build a small program to better wrap your head around "what" programming is.
I just think of the thing I want to build, and I break it into smaller and smaller bits.
I don't write code on paper.. just the "what do I want to happen".. super high level.
I handle the things i'm aware of in the code, and I cant test for things i'm not aware of so it makes no sense to me. Generally once I've built something that's it bombproof, nothing stops working because there is no reason for it to.
Testing. Always test the system. Automate every test you can so you can trigger them and get a report once completed rather than wasting your time clicking buttons or typing in commands.
The first is developing good habits—list out all edge cases and just manually test it out. If you work in a team, the PM, developers, and QA can brainstorm these edge cases together. It’s these simple things that make a huge difference and you’d be surprised how many teams don’t do this.
Keep in mind though that tests are also software built by humans that can be wrong too, sometimes giving you false confidence about correctness.
The best test of a system is always real-world usage.