Why Testing Shouldn’t be an Afterthought for the Growing Developer
UI Developer
projekt202
I have observed, as I am sure many developers have, that testing seems to be treated as an afterthought in the professional development and education of many software engineers.
I did not pursue a four-year degree in technology, but rather went through a “bootcamp” where I gained the skills necessary to be a successful UI developer. We spent only a single day on automated testing during my 13-week course. This barely scratched the surface of what testing is capable of, and even more so why it is important. While the course I took was largely limited by time, I found a similar mindset at my first development job. Testing was simply not a priority.
While I didn’t know much past the basics of testing, I did feel that maybe it was something more important than was being let on. Once arriving at projekt202, I found that to be, in fact, true.
I used to think that testing was something you should do purely for posterity’s sake. Writing tests for your code is what “good” developers do. I never gave much thought as to the why or even the how. As it turns out, testing had far greater implications for my growth as a developer and the quality of my code than I’d realized.
At its core, testing exists to improve your code — not just the code you currently have, either, but the code you’ve yet to write. Further still, it exists to improve the code of other developers who may someday maintain your code. When fully realized, the act of testing improves not only your code but your skills as a developer.
Potentially my favorite (once my least favorite) aspect of writing tests is that it slows me down. Testing forces you to declutter your implementation and make it singular in focus.
Complex code is complicated to test.
When your code does more than one thing, it creates a combinatorial problem in how many test cases exist. Complex code also burdens test cases with a significant amount of boiler plate and setup. If my code has numerous dependencies, I most likely need to configure multiple mocks.
Simple code is easy to test. Simple code is also easy to maintain. The easier something is to test, the easier it is to maintain. I now approach issues with more care taken as to how I can achieve my goal. I plan and then execute, rather than just throw code up and see what sticks. In order to speed up, you must slow down.
Testing teaches (let’s be honest, forces) you to think about edge cases in your code. Not just non-functional scenarios like SQL injection attacks, but simpler and potentially unexpected variations of your feature.
When you’re writing code, it can be difficult to take off the blinders. However, it is vital to focus not just on what you may know the purpose and functionality of your code to be, but all of the ways other people may utilize it.
For example, let’s say you’re building a component in a library that other developers will use in their applications. You might have the idea that a certain method only takes a certain input, but that approach might not work for another developer’s application. Let’s say you have a method that populates a table. Maybe you’d imagine that you would just need to pass in strings that would be used, but what if a developer needs to pass in numbers? Here, the act of testing forces you to become a consumer of the code you write, thinking through various use cases, often leading to code that is more flexible and reusable.
Another important consideration beyond consumer input is what occurs if your dependencies fail. What happens if your AJAX call returns 401? How does your code respond to failure? If you are only coding within your narrow blinders of your expectations for the code, you might not think of those edge cases, and the code might break for those other developers, resulting in frustrations and losing valuable time refactoring that code. If you’d been testing from the start, you’d likely have thought about ways your code might break and caught those edge cases, creating more resilient code that responds to failures appropriately.
Utilizing testing as a core part of your development cycle — rather than an afterthought — empowers developers to produce clearer, more thoughtful code, with greater considerations for further edge cases and scenarios.
Automated testing is an upfront investment in the long-term maintenance of your project. It does slow you down, but it aids in preventing your application from becoming a jumbled mess.
Investing now prevents “this will take too long to implement” later on down the road. It should be a fundamental part of any education, both before and during a developer’s professional career. Thankfully, with things such as TDD becoming more popular, testing is seeing a renewed focus and attention. This focus is powered by new practices and technologies that seamlessly integrate testing into any developer’s workflow. Now, more than ever, it is easier to take your abilities to the next level with the proper utilization of testing.
As a company, projekt202 not only understands this, but embraces and actively requires this within the organization. Younger, less experienced developers are shown the importance of it with time and care, fostering an understanding that grows with the developer throughout their career at projekt202 and beyond. It’s that time and energy spent on this and many other consequential, often-neglected concepts and practices that produces the skillful developers that work here.
