managing-testng

name	managing-testng
description	Use when working with Testng — testNG testing framework management and analysis. Covers test suite XML configuration, group-based execution, data provider analysis, parallel execution settings, report parsing, and listener configuration. Use when managing TestNG suites, investigating test failures, or reviewing Java test configurations with TestNG features.
connection_type	testng
preload	false

TestNG Testing Framework Management Skill

Manage and analyze TestNG test suites, configurations, and reports.

Core Helper Functions

#!/bin/bash

# Parse TestNG XML results
testng_parse() {
    local report="${1:-test-output/testng-results.xml}"
    python3 -c "
import xml.etree.ElementTree as ET, json
tree = ET.parse('$report')
root = tree.getroot()
ns = {'': root.tag.split('}')[0].strip('{')} if '}' in root.tag else {}
prefix = '{' + ns[''] + '}' if ns else ''
suite = root.find(f'{prefix}suite') or root
print(json.dumps({
    'name': suite.attrib.get('name',''),
    'duration_ms': suite.attrib.get('duration-ms','0'),
    'passed': int(suite.attrib.get('passed','0')),
    'failed': int(suite.attrib.get('failed','0')),
    'skipped': int(suite.attrib.get('skipped','0'))
}, indent=2))
" 2>/dev/null
}

MANDATORY: Discovery-First Pattern

Always discover suite configuration and test groups before querying specifics.

Phase 1: Discovery

#!/bin/bash

echo "=== TestNG Suite Files ==="
find . -name "testng*.xml" -o -name "suite*.xml" 2>/dev/null | grep -v build | head -10

echo ""
echo "=== Suite Configuration ==="
SUITE_FILE=$(find . -name "testng.xml" 2>/dev/null | grep -v build | head -1)
if [ -n "$SUITE_FILE" ]; then
    cat "$SUITE_FILE" | head -30
fi

echo ""
echo "=== Test Classes ==="
find . -path "*/test/java/*.java" 2>/dev/null | grep -v build | wc -l | xargs echo "Total test files:"
grep -rln "import org.testng" --include="*.java" 2>/dev/null | grep -v build | head -15

echo ""
echo "=== Test Groups ==="
grep -rn "@Test.*groups" --include="*.java" 2>/dev/null | grep -v build | grep -oP 'groups\s*=\s*\{[^}]+\}' | sort -u | head -10

echo ""
echo "=== Data Providers ==="
grep -rn "@DataProvider" --include="*.java" 2>/dev/null | grep -v build | head -10

Phase 2: Analysis

#!/bin/bash

echo "=== Test Results Summary ==="
REPORT=$(find . -path "*/test-output/testng-results.xml" -o -path "*/surefire-reports/testng-results.xml" 2>/dev/null | head -1)
if [ -n "$REPORT" ]; then
    testng_parse "$REPORT"

    echo ""
    echo "=== Failed Tests ==="
    python3 -c "
import xml.etree.ElementTree as ET
tree = ET.parse('$REPORT')
for tc in tree.iter():
    if tc.tag.endswith('test-method') and tc.attrib.get('status') == 'FAIL':
        name = tc.attrib.get('name','')
        cls = tc.attrib.get('signature','').split('(')[0]
        print(f'{cls}\t{name}\t{tc.attrib.get(\"duration-ms\",\"0\")}ms')
" 2>/dev/null | column -t | head -15
fi

echo ""
echo "=== Parallel Configuration ==="
grep -rn "parallel\|thread-count\|data-provider-thread-count" --include="*.xml" 2>/dev/null | grep -v build | head -5

echo ""
echo "=== Listeners ==="
grep -rn "@Listeners\|<listener" --include="*.java" --include="*.xml" 2>/dev/null | grep -v build | head -10

Output Rules

• TOKEN EFFICIENCY: Target 50 lines per output
• Parse testng-results.xml for structured data
• Never dump full stack traces — extract failure message only

Anti-Hallucination Rules

• NEVER guess test class or group names — discover from source and XML
• NEVER fabricate test results — parse actual TestNG reports
• NEVER assume suite structure — check testng.xml configuration

Safety Rules

• NEVER modify suite XML or test files without user confirmation
• NEVER delete test reports without user approval
• Be aware that parallel execution settings affect resource usage

Output Format

Present results as a structured report:

Managing Testng Report
══════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Counter-Rationalizations

Shortcut	Counter	Why
"I'll skip discovery and check known resources"	Always run Phase 1 discovery first	Resource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"	Follow the full discovery → analysis flow	Quick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"	Audit configuration explicitly	Defaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"	Always check relevant metrics when available	API/CLI responses show current state; metrics reveal trends and intermittent issues
"I don't have access to that"	Try the command and report the actual error	Assumed permission failures prevent useful investigation; actual errors are informative