TestNG support

Detection#

TestNG projects are identified through files such as testng.xml, Java dependencies, and matching test source.

Detection also accounts for Java project structure and conventional test folders. In repositories that contain both JUnit and TestNG, framework labels keep the current snapshot and historical activity distinguishable.

Parsed information#

Test Chronicle records annotated test methods, source files, line numbers, Java class names as parent groups, and TestNG groups as tags. Disabled tests are omitted.

TestNG dataProvider and parameters metadata are detected and flagged as parameterised definitions. Runtime cases are not currently expanded into individual tracked definitions.

Limits and configuration#

Test Chronicle tracks source definitions, not every runtime invocation produced by TestNG suites or data providers. Generated test sources, archived suites, and copied examples should be excluded when they are not part of the maintained test inventory.

Use test discovery to constrain TestNG directories and testing classification when path conventions indicate unit, integration, or end-to-end intent.

Repository-linked activity#

Parsed tests participate in project timelines and change classification, with commit, contributor, date, and framework context retained.

This makes TestNG history useful during Java modernisation work. Teams can see whether suite changes are concentrated in one package, whether disabled tests were removed, and which commits explain broad changes in test inventory.