I graduated in 1990 in Electrical Engineering and since then I have been in university, doing research in the field of DSP. To me programming is more a tool than a job.
Disclaimer: I'm not a professional programmer (I do research in DSP, therefore programming for me is a tool, not a job; well, it is an hobby too... 😊), therefore I never wrote software as part of a larger team, etc.
Nevertheless, I am very test-oriented. Without going to the extreme philosophy of test driven development, when I have to write some quite complex piece of software I start from the simplest components/packages (that will be used to write other components/packages) and I test them as thoroughly as I can. If possible, I aim for an almost 100% coverage in order to be quite sure that the component works correctly. It feels good to use my "foundation components" with confidence. Moreover, it is easier to find bugs in the isolated component rather than when it is interacting with the rest of the code.
In recent times I am learning to use formal checking techniques that I plan to integrate with (or use in place of) traditional testing.
On a side note, I love to spread my code with "bug traps" (I program in Ada, not very mainstream, I know...) such as contracts, type invariants and assertions. Bug hunting gets soooo much simpler... 😉
Thanks for the reply. I agree with that feeling you get when your components are well tested! I have my tests and transpile steps in watch mode and I love that with the tests and type assertion (we use Typescript) I can make changes and instantly get feedback on the impact. Then I can either roll back the small change and think again or make the other changes needed to make the code work again. This way you code is nearly always "working". Also, I am now going to look at a way to get Bug Traps into my code. It is a great idea!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Disclaimer: I'm not a professional programmer (I do research in DSP, therefore programming for me is a tool, not a job; well, it is an hobby too... 😊), therefore I never wrote software as part of a larger team, etc.
Nevertheless, I am very test-oriented. Without going to the extreme philosophy of test driven development, when I have to write some quite complex piece of software I start from the simplest components/packages (that will be used to write other components/packages) and I test them as thoroughly as I can. If possible, I aim for an almost 100% coverage in order to be quite sure that the component works correctly. It feels good to use my "foundation components" with confidence. Moreover, it is easier to find bugs in the isolated component rather than when it is interacting with the rest of the code.
In recent times I am learning to use formal checking techniques that I plan to integrate with (or use in place of) traditional testing.
On a side note, I love to spread my code with "bug traps" (I program in Ada, not very mainstream, I know...) such as contracts, type invariants and assertions. Bug hunting gets soooo much simpler... 😉
Thanks for the reply. I agree with that feeling you get when your components are well tested! I have my tests and transpile steps in watch mode and I love that with the tests and type assertion (we use Typescript) I can make changes and instantly get feedback on the impact. Then I can either roll back the small change and think again or make the other changes needed to make the code work again. This way you code is nearly always "working". Also, I am now going to look at a way to get Bug Traps into my code. It is a great idea!