Tests that catch a break before your users do
We write automated tests for your back-end, from business rules to the contracts between services, and run them on every change.
Who it's for
For companies where every fix breaks something else and nobody dares to touch the code.
What it solves
- Fixing one bug creates another, which only shows up in production.
- A change to the API breaks the app or a partner's integration, and nobody was warned.
- The existing tests fail for no clear reason, so nobody trusts the result.
- Testing a version depends on someone clicking through everything by hand before release.
What we do
- Unit tests
- Business rules tested in isolation, including the edge cases that cause the most bugs.
- Integration tests
- Real databases, queues and external services, started in containers during the test.
- Contract tests
- API consumers and providers agree the format; a breaking change is caught before release.
- Brazilian scenarios
- Repeated payments, rejections and timeouts in Pix payment and tax document flows.
- Test data
- Fictitious, reproducible data created by the test itself, without copying real records.
- Flaky tests
- Tests that fail at random are investigated and fixed, not switched off.
What you get
- A suite of unit, integration and contract tests in your repository
- Tests running in the pipeline on every change, blocking on failure
- A report on what is covered and what is not yet
- A documented test data strategy
- A guide for your team to write new tests in the same style
How we do it
Risk map
Which flows hurt most when they break and which already have some tests.
Test foundations
Tools, test data and a container-based environment set up for the team.
Critical flows
Tests for the highest-risk flows first, then the rest.
Contracts
Contracts between the back-end, the apps and the integrations, checked on every version.
Pipeline
The tests start deciding whether a version goes ahead or stops.
Technology examples
- Pact
- Testcontainers
- JUnit
- pytest
- Jest
- WireMock
- Playwright
Related services
FAQ
What test coverage do you aim for?
We do not work to a fixed number. We would rather cover the flows that cost most when they break than chase a percentage that includes code with no risk.
What is a contract test?
A test that checks whether the caller of an API and its provider still agree on the format. If a change breaks that agreement, the test fails before release.
Can you test against the bank's or SEFAZ's test environment?
Yes, where the bank or authority offers one. Because those environments are not always available, most tests use simulations, and the external environment is kept for a final check.
Do tests slow development down?
At first, a little. Over time, the team tends to spend less time fighting fires in production and changes the code with more confidence.
Write to Balkan
Talk to us about your project