By using a sustainable testing strategy, you can skip unnecessary tests, ensure failing fast and early, and only run tests affected by code changes, Jochen Joswig suggested in his talk about DevGreenOps at OOP Conference. Tracking energy use per test and using static code analysis can help spot inefficiencies and guide optimization efforts.
Sustainable testing starts with setting up a proper testing strategy, Joswig mentioned. This ensures that no unnecessary tests and test cases are executed, which not only reduces the time it takes to do testing, but also ensures that your testing follows the minimalism and efficiency criteria, he added.
Joswig also recommended reducing the number of executed tests to what’s absolutely necessary:
By designing the testing strategy, so that tests fail fast and early, because once a test fails, the execution of the rest can be halted, thus saving energy and time. Typically unit tests run first, catching an error here means that no integration test, end to end test, UI tests, etc. must be run.
He suggested executing only tests that test the code that has changed. This is particularly true for all automated tests in monorepo projects. When only the frontend code changes, then there is no reason why the backend code should be tested and vice versa, he mentioned. You can go into even smaller detail and run static code analysis first, and then only execute the affected tests, he added.
If you want to improve your automated test setup, you can try to track energy consumption of each individual test during execution and feed that into your observability stack, raising alarms if certain methods or runs exceed energy thresholds, to incentivise reengineering of parts of the code to optimize performance, Joswig mentioned.
If you cannot extract energy consumption information, but you still want to optimize the transparency of your tests, you could use proxy metrics like MB transferred, time, CPU and Memory utilization, he added.
Joswig recommended running static code analysis to test for easy-to-spot inefficiencies in the code, for instance, sending backend calls or database queries from within a loop. He mentioned that there are several tools available:
There is Creedengo, an open-source plugin for SonarQube. It supports Java, and also other languages like Python, JavaScript, and C#. There are also closed-source alternatives, which may come with an even wider support for detecting inefficiencies in the codebase, or which can handle other and/or more languages than Creedengo. However, since these are pay-to-use, I personally could not yet verify this.
Creedengo comes with a caveat, though. Some of its rules have a negligible impact on performance and energy consumption. Therefore, it is important to hand-pick a useful subset of rules, Joswig mentioned.
Guided by the motto "the greenest code is the code you never write", Joswig stressed the importance of testing early in the development life-cycle with low-fidelity click-dummies or paper prototype tests, to ensure that development teams focus on features that actually add value and matter to users:
Sustainable testing or green software development in general is a team effort, and everyone can contribute. Even the PO, when specifying that weaker and older hardware or operating systems must be supported, and subsequently instructing the team to test on such devices for compatibility and usability.
The resulting extended lifespan of the hardware reduces emissions and harmful effects associated with replacing said hardware. It leaves the question of how many test devices a team needs, where Joswig suggested as few as possible, but as many as absolutely necessary.
InfoQ interviewed Jochen Joswig after his talk.
InfoQ: Why should we track energy consumption during testing?
Jochen Joswig: Tracking the energy consumption gives developers more insight into how much energy each part of the application consumes and where the potential for future improvements lies.
A similar approach has led to the vital discovery of a critical vulnerability, which is now listed in the NIST national vulnerability database under CVE-2024-3094. In his Mastodon post, Andres Freund describes how he found a security vulnerability almost as a byproduct of his testing.
Given the gravity of the vulnerability, one can ask if finding it should have ever been left to chance, especially because it shows that software development teams stand to learn a lot about their software, with the potential to affect every part of it.
InfoQ: What do you expect the future will bring when it comes to sustainable software development?
Joswig: I expect the electricity demand for software development to increase in the next few years. This increase in demand could lead to an increase in cost; hence, the cost of energy and hardware will remain a factor and will determine the profitability of innovations. Increasing efficiency will become a focus, if not even a competitive advantage.
We will see motivated individuals, institutions, universities, and companies, as well as communities and open source projects, raise awareness and pave the way to a necessary greener digital future. I expect lots of knowledge, tools, and other contributions in various forms will come from this.
The free market sector might take a while to adopt green software best practices. Governments, especially in the EU, have IT sustainability already on their radar, and I expect contracts and tenders issued by governmental organs to include points on IT sustainability and sustainable software, hopefully creating a cascade of adoption throughout the supply chain.