Test reporting in pipelines in Testing Fundamentals - Framework Patterns

Framework Mode - Test reporting in pipelines

Folder Structure of a Test Project with Reporting in Pipelines

  test-project/
  ├── tests/                  # Test cases organized by feature or module
  │   ├── login.test.js
  │   ├── cart.test.js
  │   └── checkout.test.js
  ├── reports/                # Generated test reports (HTML, JSON, XML)
  │   └── latest-report.html
  ├── config/                 # Configuration files for environments and test settings
  │   └── config.json
  ├── utils/                  # Helper functions and utilities
  │   └── logger.js
  ├── ci/                     # CI pipeline scripts and configs
  │   └── pipeline.yml
  ├── package.json            # Project dependencies and scripts
  └── README.md               # Project overview and instructions
  

Test Framework Layers for Reporting in Pipelines

• Test Layer: Contains the actual test cases that run the application scenarios.
• Reporting Layer: Collects test results and generates readable reports (HTML, JSON, XML).
• Configuration Layer: Holds environment settings, test parameters, and report output paths.
• Utility Layer: Provides helper functions like logging, screenshot capture, and report formatting.
• CI/CD Integration Layer: Scripts and configs that run tests and publish reports automatically in pipelines.

Configuration Patterns for Test Reporting in Pipelines

Use a central config file (e.g., config/config.json) to define:

• Test environment URLs (dev, staging, production)
• Browser or platform settings
• Report output directory and formats
• Credentials or tokens (securely managed)

In CI pipelines, pass environment variables to override configs for flexibility.

Example snippet from config.json:

{
  "env": "staging",
  "baseUrl": "https://staging.example.com",
  "reportDir": "reports",
  "reportFormat": "html"
}

Test Reporting and CI/CD Integration

Test reports provide clear pass/fail results and details for debugging.

• Generate reports in formats like HTML for easy viewing, JSON/XML for tools.
• Store reports in a dedicated reports/ folder.
• Configure CI pipelines (e.g., GitHub Actions, Jenkins) to run tests and archive reports.
• Use pipeline steps to publish reports as build artifacts or send notifications on failures.

Example CI step snippet (YAML):

steps:
  - name: Run Tests
    run: npm test -- --reporter=html
  - name: Archive Reports
    uses: actions/upload-artifact@v3
    with:
      name: test-report
      path: reports/latest-report.html
  - name: Notify Team
    if: failure()
    run: echo "Tests failed! Check report." | mail -s "Test Failure" [e-mail]

Best Practices for Test Reporting in Pipelines

1. Automate report generation: Always generate reports automatically after tests run.
2. Use readable formats: HTML reports are easy for humans; JSON/XML help integration with tools.
3. Archive reports in CI: Keep reports accessible for review and historical tracking.
4. Fail fast and notify: Configure pipelines to fail on test errors and notify the team immediately.
5. Keep configs flexible: Use environment variables to switch report settings without code changes.

Self-Check Question

Where in this folder structure would you add a new script to send email notifications after test reports are generated?

Answer: In the utils/ folder, as a helper utility for notifications.

Key Result

Organize tests, configs, and reporting tools to generate and publish clear test reports automatically in CI/CD pipelines.