Using Acceptance Tests to Safely Evolve Complex Business Systems

The Challenge: High-complexity Domain Projects Leading to Slow Delivery

Financial systems tend to contain a large number of edge cases; a loan may follow its original repayment schedule, but it may also be partially paid, refinanced, delayed, restructured, or moved into default.

4Finance had a Java monolithic back-office that was in charge of all the calculations needed for the whole lifecycle of a loan.

In environments as complex and intricate as this, even seemingly simple changes can become risky. Developers spend significant time validating assumptions, QA cycles become longer, and teams naturally become more cautious when deploying new versions.

The challenge was not only building new functionality, but doing so without breaking years of accumulated business behaviour.

The Mitigating Factor: Iterative Acceptance Testing with Cucumber

The engineering team worked on unit, integration, and acceptance tests. But the acceptance test suite became the most valuable layer because it represented the business language of the system itself.

The AT project was simple: a Cucumber implementation full of organized test cases. The key factor was not specifically the framework, but the ability to express business rules as executable specifications that could be understood by developers, QA engineers, and business experts alike.

Using Gherkin, the tests looked like this:

Feature: Client defaults after some instalment was paid

    Background:
        Given a client opens a loan for 300€
        And there are 12 instalments

    Scenario: Client pays all the instalments on time
        When client has paid 12 instalments on time
        Then loan is closed

    Scenario: Client defaults after 6 payments
        Given client has paid 6 instalments on time
        When client defaults on the 7th payment
        Then remaining payment includes penalties

    Scenario: Client defaults after 6 payments and then closes the loan
        Given client has paid 6 instalments on time
        When client defaults on the 7th payment
        And client pays all instalments
        Then loan is closed
  

Underneath the simple Gherkin code, there were Groovy scripts that would make the API calls and perform the browser actions necessary using Selenium when necessary.

Making Acceptance Tests Part of the Workflow

Whenever a bug or unexpected behaviour was discovered, the first step was often to capture it as an acceptance scenario. This created a reproducible example of the problem for developers, while QA engineers expanded the initial scenario with additional variations and edge cases.

As both the back-office and the Cucumber project were mature, most changes required only adding or updating scenarios.

The project was integrated into their Jenkins CI/CD pipelines, so every commit on a PR would undergo this acceptance test project.

Over time, the suite became a catalogue of business knowledge, preserving past bugs, edge cases, and requirements as executable specifications. For a system containing years of accumulated business logic, this confidence became one of the team’s most valuable assets.

Drawbacks

Acceptance Tests are not a silver bullet.

They do not replace unit tests, integration tests, monitoring, performance testing, or good system design. They also introduce maintenance costs and require discipline to keep scenarios readable and relevant.

On an already running project, it may reprensent a significant investment to implement, if there is a knowledge gap and/or significant technical debt.

However, it can mitigate a great deal of problems high-complexity systems usually suffer. The main benefit is simple: a robust, comprehensive suite of tests grants confidence that the business workflows and logic will behave as expected after every change.

Final Thoughts

In my professional experience, I have had to work with very different projects, architectures, technologies and delivery setups.

This remains one of the environments where I felt the highest level of confidence when deploying changes. It was not a specific framework or tool, but the deployment confidence that the test suite gave us on any behaviour change.