Clean Coding Processes are a Must: And We aren’t Talking Just Writing Code!
A skilled software developer will spend lots of effort to create and maintain good code structure. Naming classes and methods consistently, putting them into the right packages, grouping them correctly, and adopting good processes are all part of this major task.
While clean coding is essential for writing code, its importance in test code is often overlooked. This results in a division of opinions on how to write tests, so if you’re looking for some consistency when it comes to code base testing, you’ve landed the right article.
Let’s look at some guidelines we at SFL follow to keep test code organized when working on Java projects.
Testing and product quality
Nobody wants to be known for their mistakes and neglecting attitude, and this is especially true of Testers.
From the moment a tester is assigned any application to test, he or she takes the responsibility for supervising the quality of that application and this is good opportunity to put their skills at work.
The phrase “End to End” testing is rather accurate from that perspective as it shows that testing needs to be complete.
The Approach to testing at SFL
We at SFL acknowledge how important proper test setup is for having quality products.
For this, we make sure that the test setup contains unit tests, integration tests and end-to-end functional tests.
Unit tests and integration tests
Unit & Integration testing practices together with TDD are considered cornerstones and essential must- haves of any modern software platform.
The expected standard in the software development industry is having 70% + unit tests coverage on the business, persistence and facade layers of the application, and we at SFL make sure to adhere to these standards. Another remarkable metric of the well-designed testable application is the presence of 3 to 1 ratio in the unit tests VS application code. Putting it differently, it means that for each line of code in the business layer there must be 2–4 lines of unit testing code.
Failing to meet the criteria above puts any project functionality and future maintenance under great risk.
So, what happens if there’s no adequate unit test coverage?
The lack of unit tests introduces several critical risks:
- There is no way to automatically assess whether a change in the code base affects other parts of the platform
- It marginally slows down the pace of adding new functionality to the code base
- As the platform grows, the code base becomes unmanageable
- Defects popping out of the system randomly after each deploy, and the remarkable fact is that the number of such defects is exponentially raising depending on the size of the application
- The support and maintenance of the existing platform can cost up to 5x — 20x more (depending on the code base size) when compared to the software platform which has appropriate unit test coverage.
- The architecture of the application is degrading over time.
While this is a rather large list, it still isn’t exhaustive. There are many more pitfalls of the unit tests, the most remarkable ones being the marginally increased support/maintenance cost and depleting customer satisfaction because of the high number of defects.
Some important steps to take
Keeping code covered
Having good code coverage is no easy task, and even if your team decides to stick to that goal, it may not often be successful. As projects progress, or as the team grows, important logic can end up uncovered by tests like when one of the team members needs to make a quick fix or you’re in a bit of a rush at the end of the sprint and some features still remain unfinished.
What’s our tip? To keep code well-tested, the most important thing is to have common understanding across the team. It’s essential that team members understand how important tests are, and the benefits they bring. Otherwise, there’s no point in writing them!
Keeping tests clean
While this may sound as a no-brainer, developers often try to refactor production code and forget that the same clean code rules should apply to test code. If test code is in a constantly chaotic state, changes for class or function will end up being untested — no one will want to touch that mess of code. For such tests, developers will usually change the production code, and then attempt to fix the failing tests by changing assertions to expect new behavior.
Enforcing code coverage
A typical approach to this is setting up a specific number: say 80 or 90 % of code coverage where fail builds if coverage drops. This approach is frequently used by clients when they want to take over support to their IT departments once the project is completed. The main issue with this approach is that it forces developers to reach a certain goal but doesn’t specify how. This can lead to sloppy tests, or tests written just for coverage.
Using pull requests
This method is similar to enforced coverage, but instead of using some code-scanning tool, it uses the team itself. It’s a good idea to have some common rules and agree that every team member should check them in pull requests. For example, “If the bug is fixed, then it should have a test for the case that was causing the bug.” This not only this encourages better code coverage, it ensures that tests can be reviewed in the same pull request.
End to End testing practices
The goal of End to End tests is to verify the product or a service as a whole. It is performed from start to finish simulating real user scenarios.
The tester aims to determine various dependencies of the application being tested as well as ensuring that accurate information is communicated between various system components.
Automated end to end testing helps to minimize the time spent on repetitive manual checks covering main user flows. While machines are responsible to run those scheduled repetitive tests, engineers can spend their time on designing new test cases to cover newly delivered features.
End to end testing at SFL
When it comes to end to end testing, we at SFL are committed to adhering to coding standards for end to end tests. This means these tests have to be independent and isolated from each other. Also, each test needs to cover one specific flow.
This allows to:
- Ensure complete correctness and health of the application
- Increase confidence in the application
- Reduce future risks
- Decrease repetitive efforts
- Reduce costs and time
P.S.
Good code structure is truly an important practice for software developers, but it’s also crucial for testing code. What are some of your structure practices? Let us know in the comments!
About this author:
Sona Sahakyan is a Bug Hunter and a tech enthusiast working at SFL.
