Hi. I'm here to tell you something that you maybe don't want to hear. But that's my role as an opinionated person who happens to work in technology (or so I was raised to believe that having an opinion is good, but I think that's very context dependent).
You should be writing tests. Oh my. I know, you've heard it all before, right? Often times it comes forth as some type of obligation to the greater good, or that this is just what good developers do. Who are these "good" developers? The pedantry! Who has time for this crap!
Well most of all, you should do it for YOU. Because you want a saner professional existence, you want to build your technical chops, and you want your teammates to be able to understand what you contributed without having to get pinged to oblivion and back, each time explaining some facet of your understanding and implementation. Doesn't that sound great?
Understand your codebase and chosen language
This is a very practical driver for adopting a testing ethos. Building out tests and getting the code to run has often forced me to dive into the technicalities of my work, and enabled me to approach intended outcomes from differing angles. It forces me to break up larger methods into smaller ones, and along the way I find myself comprehending the existing code base in a way I wouldn't by just jumping in and building on top of it. I notice that having a passing test enables me to refactor and reuse existing code with higher levels of certainty. If the test breaks, I can revert it, go back and figure out where I went wrong.
A test enables the conceptualization of the end goal and creates space for utilization of existing language features. It holds the end goal in place and frees the writer to find out, hey, does the language natively support in pursuit of our goal? If not, is there a library out there, or a pre-designed solution?
Or maybe it's worth trying to integrate a framework feature I've been hearing about and have been meaning to explore. No matter what path is chosen, the test provides consistent feedback as to whether what's being attempted is moving the code closer to the goal. Even when it passes, the writer becomes free to try new things, see if it breaks the test, and explore how it creates that breakage.
Externalize your inner thoughts and processes
So great. There are tests, and we've made them pass. Dependent upon the testing framework, now your co workers can (easily?) read the tests to comprehend just what the heck this code is supposed to do. No test is going to bestow complete and total understanding, but the absence of a test deprives a third party of another avenue for contextualizing the code. That's valuable both in the PR stage and when adding a fix or feature to the code.
By writing out the tests, you're also explaining your own logic to yourself and giving yourself an opportunity to revise. It's like a journal. But a work oriented, extremely technical journal. Writing out these tests will also tie into your general writing skills. If you can express yourself through the magic of test descriptions, then your general communication tool set is getting a kicker.
Be more confident and, if possible, happy at work
As someone who is more senior in a company, I will get thrown into a problem or an existing patch of code with which I have to build a sense of comprehension. Chances are other senior developers or code owners are busy with other projects, so this turns out to be a bit more stressful, as it's easy to break code you don't fully grasp.
If someone has done me the service of building out the tests, I can run them, make a change and run again. If it breaks, I can easily revert. This really enables me to focus on the changes I need to make without trying to understand all the side effects - when the tests break then I know I have some exploring to do.
If there are no tests, I can feel a lot better about this situation by harnessing the code as it exists, THEN making my changes. See? I'm less stressed already.
When its a new problem, building out tests also helps create a mental scaffolding. The tests help build little chunks of understanding around what is happening, and offloads the mental juggling that often comes with designing the logic. When something is properly harnessed, suddenly it no longer needs to reside in the brain, which is now free to think of other things. Most of the time this is going to be more coding concepts, but better to be reading, understanding and externalizing concepts for later reference as opposed to the wearying process of trying to keep it all in your brain.
There you have it. So write some tests. Or don't. Because really, it's about helping yourself in the long run!
Originally published at meluski.com
Top comments (0)