Has Your Test Suite Been Code Reviewed Lately? Maybe it Should!
Test code often doesn't get the respect it deserves, that’s because it’s the one piece of code that your customers will never see. It’s something that feels like it doesn’t need the polish and shine that your production code gets. This notion is all to easy to conform to, but may not be in anyone’s best interest.
At ITHAKA we started talking code review standards soon after we began building and running our automated test suites. Over the last few years we made it a habit to have our code reviewed by leads as well as peers. We iterated on the new process over time to further refine the feedback shared among the testing team. The value add of taking the time to perform this one extra step cannot be overstated!
What Have Reviews Done for Us to Enable Speed and Efficiency?
Enforce Standards
When you have a team of more than one person, you have more than one style of coding. Reviews play a major role in making sure everyone is writing code with the same standards. This ensures not just correct naming standards, but also uniformity in classes and methods, as well as making sure everyone uses the correct versions of the libraries.
More Readily Identify Inefficiencies
Writing and refactoring the same code can often make it easy to overlook improvable parts of the code — are you hardcoding values that could be data-driven? Do you have methods that are so similar they could be merged into a single method?
Share Knowledge
Does the code under review use deprecated functionality? This would be the correct time to let the team member know about the new version and update the existing code. Did you find a new, more efficient way to write something you do often? Highlight this during the review and you will have just saved someone from doing hours of research.
Onto the Next Question… How Does Code Reviewing the Test Code Affect the Big Picture?
Upgrades are Easier
With every browser version update, Selenium gets a new version which means you need to update your codebase. With reviews enforcing standards, you know what to expect when you roll out the new versions of the libraries. When a major upgrade rolls around, your whole team will have the same refactors to do. This is where you will see the difference between non-standard code and code that has been reviewed.
Creation of Customized Libraries/Gems
As the code reviews progress, the team can very easily start to spot reused code that can be separated into a library of its own. For example, a team could build a browser-making library to encapsulate all the browser manipulation or a library that only handles credentials. Testers may even work to build libraries that talk to custom applications within your environment, the list of possibilities is endless!
Creation of a Reusable Framework
By the time you create your independent libraries and base classes, you will have created a framework that you can easily fork across multiple projects. What exists within the libraries themselves can live independently from the other test code. The same holds true for the rest of the code base resulting in zero overlap while also giving teams the ability to work freely without having to worry about conflicts or dependencies on each other.
In Conclusion
A lot of our successes with using automated testing has been due to our efforts in ensuring quality in all the code we write. It can be very easy for large code bases to get “out of hand”, but following simple and easy-to-use guidelines has been a great way to maintain consistency. As always we are driven by our desire for continuous improvement and everything can always be better.
Interested in our approach? Why not join our team!
