Testland
Browse all skills & agents

currents-integration

Wires Currents.dev cross-run test analytics into a Playwright suite: installs `@currents/playwright`, authors `currents.config.ts` (env-sourced `recordKey` + `projectId`), registers `currentsReporter()`, enables trace/video/screenshot artifacts, and runs via `npx pwc` so per-test traces stream to the Currents dashboard with over-time flakiness, slowest-test, and pass-rate trends. Use when a Playwright suite needs hosted cross-run suite-health analytics; for a static per-run report use extentreports or allure-reports, and to sync results into Jira test management use zephyr-integration or xray-integration.

Install with skills.sh (any agent)

npx skills add testland/qa --skill currents-integration
View source

currents-integration

Overview

Per currents-docs (opens in new window):

"Playwright reports explain a single run. Currents explains your test suite over time, and more."

Currents.dev is a SaaS test analytics platform that ingests per-run results via runner-specific reporters and provides longitudinal views (flake rate over time, slowest-test trends, PR-level deltas). It's commonly paired with Playwright and Cypress.

This skill covers the Playwright integration; the Cypress integration follows the same shape with @currents/cypress (see references/ci-and-cypress-integration.md).

When to use

  • A Playwright suite has 100+ tests and the team needs over-time analytics: which tests flake, which tests slow down across PRs, which tests fail on certain CI runners only.
  • The team wants per-PR test diffs (this PR's failures vs main's failures) without building a custom dashboard.
  • The team is on Cypress (use @currents/cypress with the same shape).

If the suite is small (<50 tests) and the team only needs the per-run report, Playwright's built-in HTML reporter is enough - no SaaS dependency.

How to use

  1. Confirm the suite is large enough to need over-time analytics (see When to use); a small suite is fine on Playwright's HTML reporter.
  2. Install @currents/playwright.
  3. Author currents.config.ts (recordKey from env, projectId inline) and register currentsReporter() in playwright.config.ts.
  4. Enable trace / video / screenshot artifacts so Currents has per-test data to analyze.
  5. Run npx pwc; open the dashboard URL it prints.
  6. Wire the same run into CI, recording both main (baseline) and PR runs - the full workflow, per-PR-vs-main rationale, and the Cypress sister integration are in references/ci-and-cypress-integration.md.

Install

Per currents-pw-quickstart (opens in new window):

npm i -D @currents/playwright
# Equivalent for pnpm / yarn / bun.

Configure currents.config.ts

Place next to playwright.config.ts. Per currents-pw-quickstart (opens in new window):

import { CurrentsConfig } from "@currents/playwright";

const config: CurrentsConfig = {
  recordKey: process.env.CURRENTS_RECORD_KEY!,
  projectId: "your project id goes here",
};

export default config;

The recordKey is the project's record-write secret - never check it into the repo. The projectId is non-secret (visible in the Currents dashboard URL); it's safe to inline.

Register the reporter

In playwright.config.ts, per currents-pw-quickstart (opens in new window):

import { defineConfig } from "@playwright/test";
import { currentsReporter } from "@currents/playwright";

export default defineConfig({
  reporter: [currentsReporter()],
  // ... other config ...
});

The reporter forwards every test event (start, finish, attachments) to the Currents API.

Enable artifacts

Per currents-pw-quickstart (opens in new window), the use section should enable the three artifact types Currents consumes:

use: {
  trace: "on",
  video: "on",
  screenshot: "on",
}

The defaults Playwright ships with (trace: "on-first-retry") cap the artifact volume; Currents wants every test's trace to drive its analytics. For a high-volume suite, consider trace: "retain-on-failure" as a middle ground.

Run

Per currents-pw-quickstart (opens in new window):

# Reads recordKey from env, projectId from config:
npx pwc

# Or pass on the CLI:
npx pwc --key XXX --project-id YYY

pwc is the Currents-aware Playwright wrapper. It runs Playwright with the Currents reporter active and streams results in real-time; on completion, it prints a dashboard URL.

Worked example

A 120-test Playwright suite, first Currents run:

  1. npm i -D @currents/playwright.
  2. currents.config.ts alongside playwright.config.ts:
import { CurrentsConfig } from "@currents/playwright";

const config: CurrentsConfig = {
  recordKey: process.env.CURRENTS_RECORD_KEY!,
  projectId: "abc123def",
};

export default config;
  1. In playwright.config.ts, add the reporter and turn artifacts on:
reporter: [currentsReporter()],
use: { trace: "on", video: "on", screenshot: "on" },
  1. Export the secret and run:
export CURRENTS_RECORD_KEY=...     # from the Currents dashboard
npx pwc

pwc streams each test event to Currents and prints a dashboard URL on completion. After the second run on main, the dashboard's trend graphs start showing flake rate and slowest-test movement across runs.

Operating in CI

Run npx pwc from the CI job with CURRENTS_RECORD_KEY supplied as a secret, and trigger on both push to main and pull_request so the dashboard has a baseline (main) to compare each PR run against. Keep Playwright's HTML report as an if: always() artifact fallback for when the dashboard is unreachable. The full GitHub Actions workflow, the per-PR-vs-main baseline rationale, and the Cypress sister integration are in references/ci-and-cypress-integration.md.

Anti-patterns

Anti-patternWhy it failsFix
Hardcoding recordKey in currents.config.tsSecret leaks into git; bad actors can pollute the dashboard.Read from env (see Configure currents.config.ts).
Running both Playwright's default HTML reporter and currentsReporter without artifact handlingDoubled artifact size; CI runner disk pressure.Keep both reporters; rely on the if: always() upload (see Operating in CI).
Sending production / staging real-user CI runs to CurrentsMixes test signal with monitoring signal; analytics pollute.Send only test runs; production observability lives elsewhere.
Disabling trace: "on" to "save space"Currents's value is per-test trace inspection; disabled traces gut the analytics.Use retain-on-failure as a middle ground (see Enable artifacts).
Recording PR runs without recording main runsNo baseline; per-PR diff is meaningless.Record main on every push too (see Operating in CI).
Treating pwc's exit code as gate-onlyThe dashboard surfaces flake / regression context the CI exit code hides.Read both: pass/fail from CI; flake / regression from the dashboard or its API.

Limitations

  • SaaS dependency. Currents is a managed service. Air-gapped / offline CI can't use it directly.
  • Per-run cost. Recording every PR push to a public repo with 100s of tests can hit the plan's recorded-test-count quota. Consider main-only recording for low-traffic projects.
  • No first-party Jest / Mocha integration. The platform is Playwright + Cypress focused; other runners need custom JUnit XML ingestion (which loses per-test artifacts).
  • Doc URL drift. Per the redirect chain observed in this skill's source-fetch (currents.dev → docs.currents.dev → versioned paths), Currents docs occasionally move. Pin a version of the SDK package and re-verify URLs at each upgrade.

References

  • currents-docs (opens in new window) - Currents.dev overview, "test suite over time, and more" positioning, supported runners (Playwright explicit; Cypress in the references file).
  • currents-pw-quickstart (opens in new window) - Playwright integration: install, currents.config.ts shape (recordKey + projectId), reporter registration, artifact config (trace / video / screenshot), npx pwc run command.
  • references/ci-and-cypress-integration.md - full GitHub Actions workflow, per-PR-vs-main baselines, and the Cypress sister integration.
  • junit-xml-analysis - pair with Currents to keep CI gating self-hosted (JUnit) while Currents handles longitudinal analytics.
  • testrail-integration, xray-integration, zephyr-integration - sibling test-management integrations (different role: test management vs analytics).

Currents CI wiring and the Cypress integration

View source (opens in new window)

Currents CI wiring and the Cypress integration

Deep reference for the currents-integration SKILL.md. Consult when wiring Currents into GitHub Actions, coordinating per-PR vs main baselines, or setting up the Cypress sister integration.

CI integration

# .github/workflows/e2e.yml
name: e2e
on:
  pull_request:
  push:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npx playwright install --with-deps

      - name: Run tests with Currents
        env:
          CURRENTS_RECORD_KEY: ${{ secrets.CURRENTS_RECORD_KEY }}
        run: npx pwc

      - name: Upload Playwright HTML report (fallback)
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 7

if: always() on the artifact upload preserves the local report even when the Currents stream succeeds - useful when the dashboard is unreachable.

Per-PR vs main runs

The Currents dashboard separates main runs (baseline) from PR runs (comparison). For the analytics to make sense:

  • Main: every push to main records a run. This becomes the baseline for trend graphs.
  • PR: every PR push records a run; the dashboard cross-references by test name to identify "this PR introduced the flake on cart.spec.ts:42".

Set the CI workflow's branch + PR triggers (the CI integration example above) to record both.

Cypress shape (sister integration, same pattern)

The Cypress integration follows the same shape with @currents/cypress instead of @currents/playwright:

npm i -D @currents/cypress

Then in cypress.config.ts:

import { defineConfig } from 'cypress';
import { currentsConfig } from '@currents/cypress';

export default defineConfig({
  ...currentsConfig({
    recordKey: process.env.CURRENTS_RECORD_KEY!,
    projectId: 'your-project-id',
  }),
});

Run via npx cypress-cloud run (the Cypress equivalent of pwc).

Related skills

allure-reports

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to extentreports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

cobertura-analysis

Parses Cobertura XML coverage reports (the JVM-canonical format originally from the cobertura-cobertura tool, also emitted by JaCoCo `--coverage-xml`, coverage.py `--xml`, Istanbul / Jest `cobertura` reporter, gocover-cobertura, and dotnet's `coverlet`). Walks the coverage-04 DTD structure (coverage → packages → classes → methods → lines + conditions), computes per-file deltas, and emits PR-time gating verdicts. Use when the existing CI emits Cobertura XML - typical for JVM-heavy stacks and tools that ship Cobertura as a default reporter.

coverage-diff-reporter

Builds a per-PR coverage delta report from any pair of LCOV / Cobertura / JSON coverage outputs (current run + baseline from the merge target) - emits a per-file table with line% / branch% deltas, called-out new files, hidden drops (overall +0.1pp but one file -8pp), and a single-line PR-comment summary. Use when the team has coverage in CI but needs human-readable PR feedback that points at the specific file the reviewer should focus on, not just an aggregate number.

coverage-py-analysis

Configures coverage.py for Python projects - wires `coverage run` (replacing `python` for instrumentation), enables branch coverage via the `--branch` flag or `branch = True` config, manages the `.coverage` data file (single-process and `combine` for parallel pytest-xdist runs), authors `.coveragerc` with `source` / `omit` / `fail_under`, and emits the format the downstream tool needs (`coverage report` for terminal, `coverage xml` for Cobertura, `coverage html` for human review, `coverage lcov` for SaaS, `coverage json` for programmatic post-processing). Use for any Python test stack (pytest, unittest, nose) that needs PR-time coverage signal.

extentreports

Configures ExtentReports v5 for a JVM (or .NET via `extentreports-dotnet`) test run: wires `ExtentSparkReporter`, `attachReporter`, `createTest`, the `info`/`pass`/`warning`/`skip`/`fail` log chain, screenshots via `MediaEntityBuilder`, hierarchical `createNode` parent/child tests, and category/author/device labels, emitting a static HTML report alongside JUnit XML for CI artifact upload. Use when a suite on the Aventstack ExtentReports stack wants a richer per-test HTML narrative than JUnit XML gives; for code-coverage reporting use jacoco-analysis, and for hosted cross-run flakiness analytics use currents-integration.

jacoco-analysis

Configures JaCoCo for JVM projects (Java / Kotlin / Scala / Groovy) - wires the runtime agent via `jacoco-maven-plugin` `prepare-agent`, generates per-build reports (HTML / XML / CSV) via the `report` goal, gates the build via the `check` goal with element / limit / minimum rules, parses the six native counters (instructions, branches, lines, methods, classes, cyclomatic complexity), and converts JaCoCo XML to LCOV / Cobertura when downstream tools need a different format. Use when the JVM build is Maven / Gradle and the team wants the canonical JVM coverage tool - or to convert JaCoCo output for cross-language coverage aggregation.

jest-coverage-analysis

Configures Jest's built-in coverage (Istanbul-instrumented `babel` provider or V8-native `v8` provider), wires the right `coverageReporters` for downstream consumption (`lcov` for SaaS / cross-tool, `cobertura` for Jenkins, `text-summary` for terminal, `html` for human review), authors per-file `coverageThreshold` rules that focus the gate on critical paths (vs the global-only foot-gun), and parses the per-file JSON output for PR-time deltas. Use when the project tests with Jest (or Vitest, which uses the same Istanbul/V8 provider) and the team needs PR-time coverage signal that's both local-runnable and CI-gateable.

junit-xml-analysis

Parses JUnit-format XML reports (the de-facto interchange format every CI ingests - Jenkins, GitHub Actions, GitLab, Buildkite, CircleCI) into structured, machine-readable per-suite and per-case metrics tables (passed / failed / errored / skipped, time, classname, message, stack), groups failures by classname for trend analysis, and distinguishes "new failures vs flakes" by cross-referencing the `flakyFailure` and `rerunFailure` rerun elements. Use when the downstream consumer is a dashboard, script, or aggregator - not when the goal is a human-readable prose summary (use test-run-summary-author for that). Single-run, in-XML aggregation only; for cross-run cross-environment roll-ups, use a cross-run test-suite aggregator.

lcov-analysis

Parses LCOV `.info` text files (the de-facto coverage interchange format produced by gcov, llvm-cov, Coverage.py via `py2lcov`, JaCoCo via `xml2lcov`, Devel::Cover, Jest via `lcov` reporter, NYC, and most others). Extracts per-file line / function / branch metrics from the canonical record keywords (TN/SF/FN/FNDA/FNF/FNH/BRDA/BRF/BRH/DA/LH/LF), computes the diff vs a baseline, and emits per-file gating verdicts. Use for PR coverage gates that don't depend on a specific language runtime.

test-coverage-targeter

Builds a "what to test next" recommendation by combining a coverage report (LCOV / Cobertura / coverage.py JSON / Jest JSON / JaCoCo XML) with the PR's `git diff`, ranking uncovered branches by risk × cost - risk weighted by McCabe cyclomatic complexity and code-churn frequency, cost weighted by the unit-test pyramid layer (unit tests cheaper than integration than E2E). Emits a prioritized list with concrete file:line targets and the test layer recommended for each. Use when a team has the budget to write 5 - 10 new tests and needs help picking which uncovered code to target first instead of blindly chasing 100% coverage.

test-run-summary-author

Build-an-X workflow that turns a structured test-run artifact (JUnit XML, Allure JSON, TestRail / Xray / Zephyr export) plus optional release context (version, build URL, deploy target) into a narrative markdown summary for release notes, an exec status update, or a stand-up Slack post. Distinct from the per-framework parsers junit-xml-analysis / allure-reports / coverage-diff-reporter, which emit structured tabular reports: this skill takes the same data and writes the human-readable narrative. Use when a manager needs a draft release note or stand-up summary from a single run; for cross-run trend analytics use currents-integration.

testrail-integration

Syncs test runs / results / cases between an automated test suite and TestRail (Gurock / Idera) - opens a Test Run for the build (`add_run`), batches per-case results back via `add_results_for_cases` (preferred over per-test `add_result_for_case` - N+1 API calls vs 1), maps the test framework's pass/fail/skip to TestRail status IDs, and attaches build URL + version + elapsed time. Use when the team's test management is standalone TestRail (not a Jira app) and automated suites must update it without a human copy-paste step; when the TCM is instead a Jira app use xray-integration (Xray) or zephyr-integration (Zephyr Scale), and for hosted cross-run flakiness analytics rather than TCM sync use currents-integration.

xray-integration

Imports CI test results into Xray for Jira - authenticates via the `client_id` + `client_secret` → JWT exchange (Cloud) or PAT / Basic (Server), posts to the format-specific `/api/v2/import/execution/*` endpoint (`/junit` for JUnit XML, `/cucumber` for Cucumber JSON, `/nunit` / `/testng` / `/robot` for the others), and maps automated results to existing Xray Test issues via the `xray-junit-extensions` `@XrayTest(key="...")` annotation. Use when the team uses the Xray Jira app to manage Test, Test Set, and Test Execution issue types and CI must keep those execution issues in sync; for the other Jira TCM app use zephyr-integration (Zephyr Scale), for standalone non-Jira TestRail use testrail-integration, and for hosted cross-run flakiness analytics rather than TCM sync use currents-integration.

zephyr-integration

Syncs automated test results to Zephyr Scale for Jira (formerly TM4J / SmartBear / Adaptavist): picks the product variant (Scale Cloud / Squad / Enterprise), authenticates with a long-lived API token as a Bearer header, opens a Test Cycle per build, posts executions via `POST /testexecutions` (or bulk JUnit via `/automations/executions/junit`), and maps test methods to Zephyr Test Cases via `@TestCaseKey`-style annotations. Use when the team's Jira test management is Zephyr Scale; for the Xray Jira app use xray-integration, for standalone TestRail use testrail-integration, and for over-time flakiness analytics rather than TCM sync use currents-integration.