Working with large and old codebases can be a challenge. While those long-lived applications usually power our core business and highly support the financial situation of our company, making changes, adding features, or doing refactorings is usually a cumbersome task.
This is usually due to the fact many different teams and developers have been working on this codebase for a long time. As it’s quite of the case, pressuring deadlines from our product team negatively impacts the quality and maintainability of the code base. Things need to get out as fast as possible. A thoroughly written test for a new feature is either an afterthought or not taken care of at all. That’s quite bad for the health of the project.
But how can we confidently deploy our changes to production when there’s little to no test written for our code? That’s almost impossible or at least takes a lot of additional time. This time could be invested way better in implementing and designing new features.
A broken production runtime due to a small refactoring that unknowingly changed the logic on the other end of our application can result in a huge loss of money and even worse, decrease the trust of our customers and users.
Our deployment pipeline, independently of using a specific vendor like GitHub Actions, Jenkins, Gitlab, etc. are our last resort when it comes to checking and verifying the correctness of our application. A covering test suite lets us have a safety net to block any changes from being deployed when there are test failures.
But if we don’t have these tests, how can we be confident and productive? Let’s see how AI can help us here.
For this article, we’ll be using a basic Java code example. You don’t need to be a proficient Java developer but should be familiar with a programming language and software development in general to understand the benefit of the workflow we’re proposing.
Using Diffblue Cover Inside Our Continuous Integration Pipeline
Literature and our common understanding of good software development tell us that we should write tests for the code we push to production. Unfortunately, testing is often neglected and cut due to a tight schedule and demanding deadlines.
Even though we might invest time and money to write tests, there’s still a high chance that the test may be suboptimal and written badly. There’s very little information available that tells us how testing is done right.
Diffblue Cover can help us by using AI to analyze our production code and generate tests in a matter of seconds. There are many potential workflow for how we can integrate Diffblue Cover into our everyday development. One of the most effective ways is to include it in our continuous integration pipeline.
Let’s take a look at this with a use case of developing a new feature.
The Solution: Integrate Diffblue Cover into the CI pipeline
With Diffblue, we can add unit tests to an existing code base with almost no effort. This may be a legacy application where there’s little to no test coverage at all. Diffblue uses artificial intelligence to analyze each method of our source in isolation with the main goal of creating a single unit test for each behavior of our application.
Diffblue’s result is a set of human-readable unit tests that cover each behavior. This also acts as a documentation of our code and helps us bust regressions as we’ve covered the current behavioral state of our application with a set of tests.
Apart from generating this baseline set of unit tests for an existing application, there are a lot of benefits when integrating Diffblue Cover into our developer’s workflow and our continuous integration (CI) pipeline.
Imagine a everyday’s use case where our development team adds a new feature to our application. The developer in charge may be new to the project or at least has never touched the classes that are needed for the new change to be implemented.
Having little to no confidence and no unit tests available, this task would be a high-risk nightmare. However, if we let Diffblue create the baseline set of unit tests, we at least have confidence that our change won’t result in a regression.
The next benefit of Diffblue comes when our developer checks in their code change for adding new behaviour. Let’s assume the developer also detects a small refactoring opportunity along the way and includes a minor refactoring tho their commit.
Pushing the production code changes to GitHub now results in a pipeline run that will give us immediate feedback about the test results:
In our example, the tests fail because our developer unintentionally broke a test during their refactoring efforts. Albeit the developer was sure the refactoring is safe, it changed the behavior of the application and therefore it’s expected for the existing tests to fail.
Having Diffblue cover integrated to our pipeline, we’ll get this information immediately displayed to our developer in charge:
What happens next is that Diffblue will perform it’s internal analyze again and will identify the changed production code to generate and/or adjust the unit tests.
After Diffblue has done its analysis and used AI to generate the new or adjusted tests, Diffblue will commit the changes to the branch the developer is working on.
The newly committed code changes will now make our build green. Diffblue added new AI-generated tests for the new functionality as well as a change to the existing tests to make the expected test behavior match the refacotring effort. What’s now left for the developer and reviewer, is to check the git diff of the proposed changes by Diffblue. GitHub, for example, provides a dedicated diff view (check the Files changed tab) for each pull request to quickly identify what changed:
Having this view and by looking at the changes for our test code, we can use the tests as the single point of truth for the behavior of our application. If we’re fine with the tests and the changes Diffblue made, we can deploy the change with confidence.
If the newly generated tests don’t state our expected code behavior correctly, we can iterate and the developer in charge can adjust their implementation to re-trigger this CI workflow until the team is happy with the results.
This then results in the following workflow:
In our example, Diffblue saved us from rolling out a new feature with a included bug to the existing behavior of our application. Furthermore, Diffblue added the relevant unit tests for our newly implemented feature to our codebase, saving our development team precious time and making them more productive.
Summary of Using Diffblue Cover in Our CI Pipeline
With this article, we saw how we could improve our development workflow and get assistance for writing unit tests. Diffblue generates unit tests for our application using AI to analyze every path of our implementation to then automatically write human-readable unit tests.
This can be extremely beneficial when working with older code bases where there’s little to no test coverage and knowledge left in the team.
Having Diffblue Cover integrated into our development workflow, we can not only generate a baseline set of unit tests for our existing code base, but also use it for our day-to-day development to get immediate feedback on the changed behavior.
The generated diff for our unit tests becomes the main place to look at when doing code changes. Our tests act as a living documentation that states the behavior of our application. By looking at the test changes, we can immediately identify if the tests are describing the expected behavior from our stakeholders and customer.s
This lets our development team discover potential regressions quite early in the development process and frees some of their time thanks to AI-generated tests. Overall, our development team will be more productive and can spend more time on actual development rather than fixing production bugs or adding tests for an unknown code base.
What are you waiting for? Give Diffblue Cover a try.
PS: This is not a sponsored article. I gave Diffblue Cover a try and I am confident that it can help many development teams with their testing efforts.
Joyful testing,
Philip
