One of the most common questions I get from the testers I work with, is “How can I assess the quality of my code?”. It’s not an easy questions since we’re mainly talking about guidelines and less about standardized approaches.
In the first weeks of test automation projects, the main challenges include getting familiar with the technology and the tools. But once confidence on the two is increasing, it’s getting difficult to know whether you’re code has quality or not.. You know the patterns, you know the Unit Test guidelines, still specific questions require specific answers.
XUnitPatterns can be a great place to start, but there are other things that need to be addressed. Naming variables, Functional vs Structural implementation, Test Data Management, using comments in code or not, are widely discussed.
One way of doing it is ask the developers. Assuming they have great focus on readability and maintenance, developers are the most entitled to provide tips and tricks on how to improve your code.
Every tester deserves a developer to work with. While not everyone has the opportunity, here’s few tips to know whether you provide quality code in your tests:
- Use variables not hard-coded values. I don’t know what 21 or 19813 means…neither do you in 2 weeks time. Instead use: canceled_orderdId=21 or randomNumber=19813;
- If you use numbers as index to lists and arrays, make sure the variable name is suggestive enough. User myUser = users.get(2). Why 2 and not 3? Try changing myUser to something more suggestive.
- Structured vs Abstraction – choose one approach, not both. It’s confusing
- Structured — signIn.click();
- Abstraction – home.Login(user,pwd);
- Draw an imaginary line on how long a line of code should be. Scrolling left and right is not very friendly for the reviewer
- Keep a decent amount of LoC per class. What decent means for you? It depends. For me, 300+ is too much. Try to structure in different classes per specific scope.
- Feels like you duplicate code in your test classes? Try inheritance and isolate duplicate code as much as possible
- Don’t hardcode dates only if necessary. Use Date libraries instead. it’s easier to handle Date types of data when it comes to assertions rather than doing String date = “02-Mar-2017” and that extract using substring methods.
- 60 constants to define in a test class? Try to isolate them in one or more property files.
- Every test method is a story. Use variables and methods naming to enhance readability.
Have more? I’m sure you do. Just leave a comment and let’s help others in building quality checks.