Hi,
A few thoughts on your questions.
Do you run it incrementally or all at once?
This can be adapted depending on what you want to achieve.
If you only need to write tests for part of the repository, then clearly it can be easier to run Diffblue Cover on one module, or even a sub-section of the code at a time. Documentation for this (on CLI) can be found here. Note that recent releases (2025.04.02 I think) also support resuming from a module in a multi-module project, so interrupting and resuming a run as much more efficient.
Another option (assuming you use version control) is to write tests for changes to the repository. This is handled automatically in Cover Pipeline (CI integration, overview and documentation here), or can be done with the CLI using patch mode. This approach is really useful for incrementally increasing tests and cover coverage as the project evolves.
For Plugin users, there are controls within the plugin to choose how much of the project to write tests for. Also, with the more agentic approach (test review, on by default since release 2025.03.01) the reviewing of tests and human interaction makes adding tests incremental (but not automated, so much slower at scale).
How do you handle the generated tests in a team workflow?
In my experience there are two models here that depend on your team’s preferences and where you have Diffblue Cover available.
One is where the developer has Diffblue Cover locally and creates the tests as part of their normal development process either while making other changes, or before creating a Pull Request (PR). The developer then reviews these and adds them to their code when creating the PR. This then includes the tests as a part of their PR which then goes through normal review, CI/CD, etc. before merging. This generally puts the ownership of the test generation upon the individual developer.
Another approach is where Diffblue Cover is available in the CI/CD pipeline (typically using Diffblue Pipeline, but sometimes hand crafted with Diffblue Cover CLI). In this scenario the ideal is to have Diffblue Cover write tests on PRs automatically and add these tests to the PR in the CI/CD environment. This would implement the Fast CI/CD System int he reference deployments here. The tests are then reviewed/accepted as part of the usual PR review and merge process.
Any tips to keep things clean and efficient?
A few thoughts:
- Have a clear place for where Diffblue Cover fits into your workflow/processes.
- When ever you make a change, commit this, then you have clear steps along the way you can fall back to, or rearrange, or cherry-pick.
- Add a [Diffblue args file](https://Any tips to keep things clean and efficient?) and add this to your version control, this keeps the inputs to Diffblue Cover and the outputs together so you can easily recreate past runs.
[I] Would love to hear how you’re using Diffblue Cover in [a CI/CD] context too!
I hope I’ve covered some of this above.