Expectations of a developer’s skill set have evolved rapidly in recent years, moving away from the idea that a team of developers should be recruited according to the Ocean’s 11 film, where each member possesses one unique skill, which adds up to the perfect heist. In reality, many companies now appreciate the benefit of having generalist, holistic developers who can do a bit of everything. Rather than being a specialist tester, devops engineer, frontend developer or backend developer, you can be cross-skilled with an area of particular expertise (this is sometimes referred to as a “T-shaped” developer). With a team of cross-skilled developers anyone can pick up any ticket regardless of what type of development it falls under.
Having the ability to write tests is a highly desired trait as companies are hiring software developers. But be warned… writing tests can be a grind. It involves writing double the amount of code to get the same output and you’ll need to learn a testing library and all of the syntactic nonsense that comes along with it. This learning curve is uniquely challenging. You will probably see your tests go red over and over again, even though you can see your code functioning, because you haven’t yet mastered how to write the test in the first place.
So, why bother? If it takes longer to get code into production, why do companies test their codebases? Many companies accept that the short-term investment of time and energy associated with writing tests justifies the long-term payoff of having a fully tested codebase with fewer bugs that developers have more confidence interacting with. This idea of increased confidence in a codebase is a critical reason for writing tests. Picture this; I produce a feature and in two months, when Bob Smith picks up a ticket to extend that feature, he can use my tests not only as a type of documentation for how the code works, but also to ensure that any changes he makes will not break the original functionality of my code.
Bob’s happy and can crack on with his ticket, great! But how exactly do tests reduce the amount of bugs in your application? The process of writing tests means you spend time thinking about what the weak points are in your application, i.e. where it might break. Through doing this you are likely to shape or redefine your code to remove or guard against some of those frailties. For example, let’s say I’m creating a “contact us” form on a website and the script behind it will break if I don’t receive data from every field of the form. Without pausing to write tests, I’ll make the same mistake every time. I’ll fill the form out entirely and validate everything works. My code is great and I’ll wrongly assume that the user will behave exactly as I have. But, at no point have I considered that a user may submit the form before they have completed every field. By taking the time to test the feature and identify its flaws, I am more likely to see this problem and to build some protection into it. I could decide to disable the submit button until all required fields have been filled out and now I have a valuable test that I can write around my code. Testing the submit button is disabled appropriately means if, while working on the form in a month’s time, Bob removes this safeguard he will have a failing test and we’ve avoided introducing a potential bug into our system.
Testing is something that comes up repeatedly in my job as a Software Development Coach for _nology. When I speak to hiring managers during our Employment Afternoons, it is clear that they prioritise candidates who possess the knowledge of and ability to write valuable, automated tests over those that have one more tool on their CV (even when that tool was in their own tech stack!).
But, what about that steep learning curve we’ve talked about? How can you actually learn to write tests? Throughout the _nology 12 Week Software Developer Course, we tackle this by beginning to write tests as soon as JavaScript is introduced in week 3. We approach it from a number of different angles, by writing tests both before (read up on “Test Driven Development” – TDD), and after writing our code and by breaking down the code into the smallest testable units. We analyse which tests have been most useful in telling us what we needed to know. Rather than treat testing as a separate activity to writing code, we treat it as part of writing code. As a result, a number of our trainees’ have experienced an improved ability to break down and solve problems independently.
Before writing this blog, a colleague said to me that all coding is testing… I agree. Every chunk of HTML or CSS we write, we visually test by looking at the browser. Every function or class we produce in a programming language, we manually test to see if it behaves correctly. In addition to aiding your career progression, and improving the quality of your code, writing tests is the definitive step to becoming part of a professional development team and learning to write code for other people.
Want to learn the skills that will set you apart and accelerate your coding career? Get in touch to learn more about the _nology Software Developer Course. Contact our Admissions Manager, Jenna Wilson, on jenna@nology.io or give her a call on 0117 302 7773.