TestNG for Java test suites
TestNG is a runner, not a browser tool. It decides what runs, in what order, and with which data. Three things bring people here. A Java suite that takes too long. A suite that passes alone and fails when everything runs at once. And a choice between TestNG and JUnit 5 that matters less than either side claims.
01Capabilities
Structure, grouping and parallelism on a Java estate
TestNG sits underneath the tests rather than inside them: grouping, data providers, running things at the same time, and suites declared outside the code. It belongs to the Java side of the stack, and the work sits inside our QA and test automation practice rather than in a separate testing group. Our QA engineers are ISTQB certified and sit in every sprint.
- Grouping
Regression packs you can slice by risk
A large suite split into quick checks, full regression and slow integration, so the right subset runs at the right moment. On a long-lived transactional system of the kind behind our fintech work, that split is the difference between a gate and a bottleneck.
- Data
One check driven across dozens of cases
Data providers feeding the same assertion many inputs, and integration tests standing up real dependencies instead of mocking away the interesting failures. This is where coverage is cheapest per defect found, and where we push work before anyone writes a browser test.
- Threads
Running at the same time without corrupting anything
Thread-per-method or per-class only works when nothing is shared: no static fixtures, no reused accounts, no single browser session held in a field. Getting that right is what turns a suite people wait on into one they barely notice.
- Boundary
The runner under a browser suite
Where the browser tests live in Java, this orchestrates them and Selenium drives the browser. Keeping that line clean is what lets you replace one of the two later without rewriting the other, and it is a standing check in our quality audit work.
02Fit
TestNG or JUnit 5, and why layering decides more
These two have converged far more than the arguments about them suggest, so the decision is short. It is worth ten minutes, not a migration undertaken on principle. What actually decides whether a Java suite is useful is which layer each check sits in and whether the tests are independent, and no annotation fixes either after the fact. Each row below names what the suite needs, from TestNG itself to JUnit 5 or fewer, independent tests.
| Your situation | What we recommend |
|---|---|
| A large legacy pack needing declared suites, groups and ordering across classes | Use TestNGThis is where it is still clearly the stronger tool, and where the alternative needs noticeably more assembly to reach the same place. |
| An existing Java suite already on TestNG and running in your build | Keep itA runner migration costs real weeks and adds no coverage at all. Spend the same weeks on the paths nobody currently tests. |
| A new Java project with no strong existing preference | JUnit 5Parameterised tests, tags and parallel execution are all there, the tooling defaults are better, and it is what most Java engineers already know. |
| A front end in TypeScript and no Java anywhere in the build | Stay in TypeScriptA Node runner keeps tests in the language your team reads, with no JVM toolchain added to test a React application. See TestCafe. |
| The suite runs for an hour and the plan is to buy more machines | Delete the duplicatesThe answer here is fewer tests, not a bigger grid. Most inherited Java suites are top-heavy, and deleting the duplicates is the cheapest thing on this page. |
| Tests chained together, so one failure produces a page of skips | The pattern, not the toolWe break the chains and make each test own its setup. Nothing in the runner fixes a suite that cannot say which thing failed. |
Scope
We own the shape of the suite. Which layer each check belongs in, whether the tests are genuinely independent of each other, and how long the whole thing takes on a bad day. Those three decide whether it is a gate people respect or a job people rerun until it goes green. Our QA engineers are ISTQB certified and sit in every sprint. unicrew has built and tested software since 2012. We have 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system.
03Delivery
Designing a Java suite so it can run in parallel
Four decisions taken deliberately, because retrofitting any of them means touching every test in the repository.
- Decide the layers before the annotationsWhat belongs in unit tests, what belongs at the service and API layer, and the small set that genuinely needs a browser. Most inherited Java suites are top-heavy: slow tests doing work a fast one could have done in a fraction of the time.
- Make every test own its dataCreated in setup, torn down after, unique to that run. Shared accounts and shared fixtures are why suites pass alone and fail together, and they are the single biggest blocker to making the whole thing finish sooner.
- Turn parallelism on deliberatelyThread count, scope and any per-thread state written down and reviewed, rather than switched on to see what happens. Where a browser is involved, one session per thread and nothing static anywhere near it.
- Make the report something a developer readsA failure has to say which case, which data, and what the state was, with a screenshot or a payload attached where that helps. If diagnosing a red build takes twenty minutes, somebody will simply press retry. The whole loop runs through our testing and QA practice.
04Stack
What sits above and below the runner
The four neighbours of a Java suite, each with its own page if that is the call you are really making.
05Questions
Questions about running a Java suite faster
The six that come up before anyone rewrites a suite or buys more machines. If yours is not here, it is a good first message.
Yes, and on the Java side that usually means working alongside your developers rather than in a separate testing group. A brief to write more tests starts with the layering conversation, because adding slow tests to a top-heavy suite makes the pipeline worse and the coverage barely better. Team extension is managed teams; the outcome is QA and test automation.
JUnit 5 for a new Java project. TestNG when you already have it, or when you genuinely need declared suites with groups and ordering across classes. The gap that used to justify it, parameterisation and parallel execution, has largely closed, and the alternative has better tooling defaults and wider familiarity. Neither choice will be the reason your suite succeeds or fails. Layering and independence will.
Yes, and the constraint is your code rather than the runner. Every thread needs its own browser session, usually held per thread rather than in a shared field, and nothing in the page objects or helpers can be static. Test data has to be unique per thread too. Suites that break the moment parallelism goes on are failing on shared state, and the fix is in the tests.
That is usually our recommendation, and data providers are a good way to do it. Service-layer tests run in seconds, fail for one reason, and survive a redesign of the front end. Keep the browser suite for the handful of journeys where the interface itself is the risk. The trade is a faster pipeline and more defects caught for every hour of maintenance you spend.
A scoping call with a QA engineer, and usually a Java engineer too, because the suite and the system it tests are one problem. Read access to the repository and recent build history beforehand makes it far more useful than a description would. What comes back is written: which layer each part belongs in, what to make independent first, and what to remove. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a suite nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Java suite that takes an hour on a good day?
Send us the suite and how long it takes when things go badly. You get an engineer's read on which tests to move down a layer, which to make independent, and which to delete outright.