How to Use TestNG Reporter Logs in Selenium
Add useful messages to TestNG’s HTML reports from Selenium tests. Learn how Reporter.log works, where to find its output, and how it differs from listeners and application logs.
org.testng.Reporter.log(...) adds explanatory messages to TestNG’s generated HTML reports. Import org.testng.Reporter, call Reporter.log("message") from a TestNG test or its test flow, then inspect the report generated for your run. It does not create a WebDriver, perform an assertion, or replace application logging.
Minimal Selenium example
Use your project’s existing WebDriver setup and place Reporter calls around meaningful test milestones. The example below shows where to log; the driver setup and page behavior depend on your application.
import org.testng.Reporter;
import org.testng.annotations.Test;
public class SearchTest {
@Test
public void searchShowsExpectedResults() {
Reporter.log("Opening the search page");
// Use the WebDriver configured by your project.
// driver.get("https://example.com/search");
// Perform the search and assert the expected result.
Reporter.log("Submitted the search and checked the results");
}
}The calls demonstrate the reporting API, not a complete browser setup. Keep assertions as assertions: a message saying that a result was checked does not itself prove that the expected result appeared. Use short, specific messages that help a reader understand the test sequence.
What Reporter.log does
TestNG documents org.testng.Reporter for messages that should appear in generated HTML reports. Its example is Reporter.log("M3 WAS CALLED");. In a Selenium test, the same API can describe actions and observations, such as opening a page or reaching a checked state.
“Reporter logs” is an informal name for these report messages. They are distinct from:
- Application logs: messages emitted by the application or its logging framework.
- TestNG internal logging: diagnostic logging from TestNG itself. TestNG has used SLF4J as its logging facade since 7.5; its logging documentation says it does not bundle an explicit implementation by default.
- Assertions: checks that determine whether a test passes or fails. A Reporter message is not an assertion.
Where to find the messages
TestNG’s documentation says the run’s index.html is in the output directory selected when launching SuiteRunner, and that it links to other HTML and text result files. Inspect the generated HTML report for the run. The output directory and report layout can depend on how your build tool, IDE, runner, or custom reporting plugin starts and configures TestNG.
- Confirm the test actually ran under TestNG.
- Identify the output directory selected by your runner or build configuration.
- Open the generated
index.htmland follow its report links. - Search the relevant test result for the message you logged.
Do not assume a Reporter message must appear in the IDE console. Console output and generated report output serve different purposes.
Choose the right TestNG reporting mechanism
| Need | Mechanism | Use it for |
|---|---|---|
| Add explanatory text to a test’s generated HTML report | Reporter.log(...) |
Messages associated with the test flow. |
| React to tests as they start, pass, fail, or skip | ITestListener |
Real-time lifecycle notifications. |
| Build a report after all suites complete | IReporter |
Post-run report generation. TestNG calls generateReport(List<ISuite> suites, String outputDirectory) after suites finish. |
| Export structured TestNG-specific result details | Built-in or custom XML reporting | Structured results and configurable details such as groups, result attributes, stack-trace output, and report fragmentation. |
Use Reporter messages for context within report output. Choose a listener when code must react to lifecycle events, an IReporter when you need a post-run report, and XML when a structured result format is needed.
Writing useful and safe report messages
- Log milestones that distinguish the test’s progress: page opened, form submitted, expected state checked.
- Prefer meaningful values or outcomes over repeated messages such as “step 1” and “step 2.”
- Keep assertions responsible for pass/fail outcomes; do not treat a log message as evidence that an assertion succeeded.
- Do not include passwords, access tokens, personal data, or other secrets in report messages.
- Avoid excessive messages that make a report harder to scan. Log information that helps explain or diagnose the test.
Setup and version considerations
If the project already runs tests with TestNG, Reporter is a TestNG API; the example does not require Reporter to configure Selenium. Keep the project’s existing TestNG and Selenium dependencies and runner setup, and check the versions your build actually resolves before changing dependencies. TestNG’s download page lists its release and Maven and Gradle dependency examples; verify that page and your resolved dependency when making version-specific setup decisions.
TestNG’s logging facade is separate from Reporter.log. Since TestNG 7.5, its documentation describes SLF4J as the facade and notes that an explicit logging implementation is not bundled by default. Adding an SLF4J implementation addresses TestNG or library logging configuration; it is not a prerequisite established by the Reporter API guidance for adding report messages.
Troubleshooting
The message does not appear in the report
First verify the test executed through TestNG and that the call is reached. Then locate the actual output directory selected by the runner and inspect its generated HTML report. Do not look only at the IDE console. Custom reporter or listener configuration can affect output, so check the project’s active report setup.
The test runs, but there is no expected TestNG report
Check which runner or build task launched the test and where it writes results. TestNG documents index.html under the output directory selected when launching SuiteRunner, but a build tool, IDE, or reporting plugin can determine the effective configuration and layout.
The message appears, but the test still passes after the page is wrong
A Reporter message does not validate browser state. Add or correct a Selenium assertion for the expected condition, and log a message only to provide context about the step or observation.
TestNG internal logs are missing
That is a separate logging configuration issue. Check the project’s resolved TestNG version and SLF4J implementation. TestNG’s logging documentation says it uses SLF4J as a facade from version 7.5 and does not bundle an explicit implementation by default. This does not change the purpose of Reporter.log.
A third-party report has a different layout
Custom report plugins can replace or alter default reports. ReportNG describes itself as an HTML/XML reporting plugin intended to replace TestNG’s default HTML report. Its project page lists version 1.2.2 and says it was tested with TestNG 6.14.3; treat those as the page’s stated details, not a guarantee of compatibility with every current TestNG and Selenium setup. Check the plugin’s own configuration and your project’s resolved versions.
Performance, reliability, and cost
Reporter calls add report messages; they do not capture browser screenshots or change the browser’s behavior. Keep the messages concise and useful, especially in large suites, so report output stays readable. For reliable diagnosis, pair descriptive messages with assertions and use lifecycle listeners or structured reports when the requirement calls for them. TestNG Reporter is part of the TestNG reporting workflow; no separate screenshot service is needed to add these messages.
Or skip the browser setup
If you need a screenshot artifact alongside a Selenium workflow, ScreenshotNeo is a website screenshot API and MCP server. Its API takes a URL and returns a PNG, JPEG, WebP, or PDF. It does not replace TestNG Reporter messages or assertions.
One request, using the documented API pattern (see the ScreenshotNeo API documentation):
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpScreenshotNeo accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, with response headers indicating the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents using Claude, Cursor, or another MCP client. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for ScreenshotNeo’s free 1,000 screenshots a month, with no card required.
FAQ
Does Reporter.log make a Selenium test pass?
No. It adds a message to report output. Use Selenium assertions to decide whether the expected browser state was reached.
Can I use Reporter.log outside a test method?
The API can be called from relevant TestNG test flow. The exact report association and output depend on where and how the call runs, so verify it with the runner and report configuration used by your project.
Is Reporter.log the same as SLF4J logging?
No. Reporter messages are intended for generated HTML reports; SLF4J is the facade TestNG uses for its internal logging integration from version 7.5.
Does every runner generate the same report files?
No universal file layout is established here. TestNG documents an output-directory index.html for SuiteRunner, while runners and report plugins can affect the actual output and layout.
