Screenshot attachment on failure in Selenium Java - Framework Patterns

Framework Mode - Screenshot attachment on failure

Folder Structure

src/
├── main/
│   └── java/
│       └── com/example/project/
│           └── pages/           # Page Object classes
├── test/
│   └── java/
│       ├── com/example/project/tests/   # Test classes
│       ├── com/example/project/utils/   # Utility classes (e.g., ScreenshotHelper)
│       └── com/example/project/listeners/ # TestNG listeners for failure handling
└── resources/
    └── config.properties       # Configuration file

Test Framework Layers

• Driver Layer: Manages WebDriver setup and teardown (e.g., WebDriverFactory class).
• Page Objects: Classes representing web pages with locators and actions.
• Tests: TestNG test classes containing test methods.
• Utilities: Helper classes like ScreenshotHelper to capture screenshots on failure.
• Listeners: TestNG listeners (e.g., ITestListener) to detect test failures and trigger screenshot capture.
• Configuration: Properties files and classes to manage environment settings and browser choices.

Configuration Patterns

• Use a config.properties file to store environment URLs, browser types, and credentials.
• Load configuration in a utility class (e.g., ConfigManager) to provide values to tests and driver setup.
• Allow browser choice via system properties or config file for flexibility.
• Configure TestNG XML to include listeners for automatic screenshot capture on failure.

Test Reporting and CI/CD Integration

• Integrate TestNG reports with screenshot attachments for failed tests.
• Use TestNG ITestListener to capture screenshots and save them with timestamped filenames.
• Include screenshot paths in TestNG reports or custom HTML reports.
• Configure CI/CD pipelines (e.g., Jenkins) to archive test reports and screenshots as build artifacts.
• Optionally, send failure reports with screenshots via email or Slack notifications.

Best Practices

• Use TestNG Listeners: Implement ITestListener to centralize failure detection and screenshot capture.
• Keep Screenshot Logic Separate: Put screenshot code in utility/helper classes to keep tests clean.
• Use Descriptive Filenames: Include test name and timestamp in screenshot filenames for easy identification.
• Store Screenshots in Organized Folders: Separate screenshots by test run date or test class for clarity.
• Integrate with Reports: Attach screenshots to reports so failures can be quickly diagnosed.

Self Check

Where in this framework structure would you add the code to capture a screenshot when a test fails?

Key Result

Use TestNG listeners to capture and attach screenshots automatically on test failure in Selenium Java frameworks.

Practice

1. What is the main purpose of taking a screenshot on test failure in Selenium Java?

easy

A. To automatically fix the test errors

B. To speed up the test execution

C. To visually capture the state of the application at failure

D. To reduce the size of the test report

Solution

1. Step 1: Understand the role of screenshots in testing

   Screenshots help testers see what the application looked like when a test failed.

2. Step 2: Identify the benefit of visual evidence

   This visual evidence helps diagnose issues faster and more clearly than logs alone.

3. Final Answer:

   To visually capture the state of the application at failure -> Option C

4. Quick Check:

   Screenshot = Visual failure evidence [OK]

Hint: Screenshots show what failed visually, not fix or speed tests [OK]

Common Mistakes:

• Thinking screenshots fix errors automatically
• Believing screenshots speed up tests
• Assuming screenshots reduce report size

2. Which Selenium interface is used to capture screenshots in Java?

easy

A. WebDriver

B. JavascriptExecutor

C. Alert

D. TakesScreenshot

Solution

1. Step 1: Recall Selenium interfaces for screenshots

   The TakesScreenshot interface provides the method to capture screenshots.

2. Step 2: Differentiate from other interfaces

   Other interfaces like WebDriver control browser, Alert handles popups, and JavascriptExecutor runs JS scripts.

3. Final Answer:

   TakesScreenshot -> Option D

4. Quick Check:

   TakesScreenshot = Capture screenshots [OK]

Hint: Use TakesScreenshot interface to capture images [OK]

Common Mistakes:

• Using WebDriver directly for screenshots
• Confusing Alert or JavascriptExecutor with screenshot capture
• Not casting driver to TakesScreenshot

3. What will happen if you run this code snippet after a test failure?

File srcFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
FileUtils.copyFile(srcFile, new File("screenshots/fail.png"));

medium

A. Compilation error due to missing cast

B. Screenshot saved as fail.png in screenshots folder

C. Runtime error because FileUtils is undefined

D. Screenshot saved but file name is random

Solution

1. Step 1: Analyze the screenshot capture code

   The driver is cast to TakesScreenshot and screenshot saved as a file named "fail.png" in the "screenshots" folder.

2. Step 2: Check for errors or randomness

   FileUtils.copyFile copies the screenshot correctly; file name is fixed as "fail.png" so no randomness.

3. Final Answer:

   Screenshot saved as fail.png in screenshots folder -> Option B

4. Quick Check:

   Code saves fixed-name screenshot file [OK]

Hint: Casting driver and copyFile saves fixed screenshot file [OK]

Common Mistakes:

• Forgetting to cast driver to TakesScreenshot
• Not importing or defining FileUtils
• Expecting random file names without code for it

4. Identify the error in this code snippet for saving a screenshot on failure:

File srcFile = driver.getScreenshotAs(OutputType.FILE);
FileUtils.copyFile(srcFile, new File("screenshots/error.png"));

medium

A. driver must be cast to TakesScreenshot before calling getScreenshotAs

B. FileUtils.copyFile method does not exist

C. OutputType.FILE is invalid for screenshots

D. File path must be absolute, not relative

Solution

1. Step 1: Check method call on driver

   The getScreenshotAs method belongs to TakesScreenshot, so driver must be cast before calling it.

2. Step 2: Verify other parts

   FileUtils.copyFile exists and OutputType.FILE is correct. Relative paths are allowed if folder exists.

3. Final Answer:

   driver must be cast to TakesScreenshot before calling getScreenshotAs -> Option A

4. Quick Check:

   Cast driver to TakesScreenshot before screenshot [OK]

Hint: Always cast driver to TakesScreenshot before getScreenshotAs [OK]

Common Mistakes:

• Calling getScreenshotAs directly on WebDriver
• Assuming OutputType.FILE is wrong
• Thinking relative paths cause errors

5. You want to attach a screenshot to your test report only when a test fails. Which approach correctly implements this in Selenium Java with TestNG?

@AfterMethod
public void tearDown(ITestResult result) {
  if (result.getStatus() == ITestResult.FAILURE) {
    File src = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
    File dest = new File("screenshots/" + result.getName() + ".png");
    FileUtils.copyFile(src, dest);
    // Attach dest to report here
  }
  driver.quit();
}

hard

A. This code saves screenshot only on failure and attaches it correctly

B. Screenshot is saved on every test, not just failures

C. FileUtils.copyFile will throw error without try-catch

D. result.getName() returns null, so file name is invalid

Solution

1. Step 1: Check condition for failure

   The code checks if test status is FAILURE before taking screenshot, so it runs only on failures.

2. Step 2: Verify screenshot saving and naming

   Screenshot saved with test method name, which is valid. Attaching to report is indicated as a comment.

3. Step 3: Confirm no errors in logic

   FileUtils.copyFile may throw IOException but typically handled or declared; this snippet focuses on logic correctness.

4. Final Answer:

   This code saves screenshot only on failure and attaches it correctly -> Option A

5. Quick Check:

   Screenshot on failure only with correct naming [OK]

Hint: Use ITestResult.FAILURE check to save screenshots only on failure [OK]

Common Mistakes:

• Taking screenshots regardless of test result
• Not handling exceptions from file operations
• Assuming getName() returns null