How DataProvider resolution works inside TestNG, why subclass inheritance requires per-class cache isolation, and what changed in 7.13.0.
Java engineer focused on tooling, testing, and developer experience.
Based in Munich.
Different JDKs, OSes, and databases reveal different behaviors. A good CI setup helps you see that early, while the change is still fresh. Define a matrix — JDK × OS × Database, any axes you need. One config, every combination, on every commit.
A suite that runs in 2 hours gets run twice a day. One that runs in 15 minutes becomes part of how you think. Tests split by historical run-time — every agent finishes at the same time, no slow batch holds the rest. You don't need to switch context while waiting for CI — everything will be ready by the time you finish your coffee.
TestNG 7.13.0 makes it practical to keep DataProviders in a parent class and reuse them across subclasses. That makes abstract test contracts, shared fixtures, and reusable test hierarchies easier to apply without duplicating parametrized coverage.
Good test integration adds readable diffs, links to the right line, and the exact input behind a parametrized failure. That gives JUnit and TestNG users clearer feedback inside the IDE and helps the next fix happen faster.
Part of working in developer tooling is contributing back to the projects the ecosystem depends on. When an improvement belongs upstream, landing it there helps maintainers, users, and the wider toolchain at the same time.
TestNG 7.13.0 adds support for keeping a DataProvider in a parent class while reusing it from subclass-based tests. That opens the door to cleaner abstract test suites, less duplicated setup, and broader parametrized coverage in real projects.
Contributed to a Sisu change used by Maven that helped resolve file-locking
problems during repeated CI builds.
The solution introduced the sisu.url.caches system property as
a safe way to disable URL caching when needed, making repeated Maven runs
more stable in CI environments.
How I think about coverage.
I usually see the most valuable tests accumulate around the paths users rely on most. Each fix leaves a test behind, and over time the suite starts to reflect real usage. That tells me more than any percentage on its own.
How DataProvider resolution works inside TestNG, why subclass inheritance requires per-class cache isolation, and what changed in 7.13.0.
The module system works best when you account for the realities of long-lived Java codebases. Here's what tends to matter in practice.
How to split a test suite so every agent finishes at the same time — the algorithm behind TeamCity's parallel test execution.
IntelliJ IDEA / Java team.
Working on Java tooling, test framework support, and developer experience around JUnit, TestNG, and JPMS.
TeamCity / Build Tools.
Worked on Maven and Gradle integrations, parallel test execution, and matrix builds.
A tool for navigating large codebases with less repetitive context gathering.
Personal CLI project for AI-assisted code navigation. It stores a persistent knowledge graph in the repository so coding assistants can query structure instead of re-reading dozens of files on every task.