Another day, another back and forth discussion on Twitter about the merits of software development.
This morning, the topic was testing, and if having untested code inherently makes that code bad. It was all kicked off when our favorite PHP mentor @coderabbi linked to the following from a conference:
All code is tested, some way or another
To me, this discussion is very nuanced, becauase in some way, we all test our code eventually. Some people prefer to have all their code come with a suite of automated tests. This is perfectly reasonable, and something most, including myself, probably strive to do.
There are other situations where we only just manually test our code. Far too many times have I written some code or made a tweak, and booted up the browser to check if it worked or not. I doubt I'm the only one. This code is still tested, to a different degree.
Now, if you ship code which hasn't been tested in any manner, whatsoever, then I wish you good luck. Because I can almost guarantee it has something wrong with it. Doing this is extremely risky, which is the main point I'm trying to make. Testing, and the manner in which you do so, is all meant to mitigate risk.
The manner in which we test our code affects the risk we take on when we ship code. Automated tests are the least risky, since they can be run quickly, and cover all areas of the codebase. Manual testing is very risky, not to mention time consuming! They tend not to be consistent, and we are unable to manually test the entire codebase when it starts to grow. And if you don't do any testing, we'll you're just inviting the worst to happen, as that code is beyond risky.
Good code is written where it provides business value and runs correctly. That's it. Good code can be written in all three of these testing scenarios. Each of them have varying levels of risk where the code written will be bad. The tests themselves aren't what dictate good vs bad code. Tests help us increase the likelihood of writing good code, but tests don't make bad code good.