Testing in Bitbucket Pipelines: Jest, Pytest, Playwright

Testing in Bitbucket Pipelines: Jest, Pytest, Playwright

Bitbucket Pipelines is Atlassian's built-in CI/CD service. If your team uses Bitbucket repositories, Pipelines is already available — no separate CI server to provision or maintain. Its tight integration with Jira, Bamboo, and the rest of the Atlassian ecosystem makes it a natural choice for Atlassian-first teams.

This guide covers setting up test execution in Bitbucket Pipelines for JavaScript (Jest), Python (pytest), and end-to-end (Playwright) test suites.

How Bitbucket Pipelines Works

Pipelines configuration lives in bitbucket-pipelines.yml at your repository root. Each pipeline run executes in a Docker container — you specify the image, and Bitbucket handles provisioning.

The basic structure:

image: node:20

pipelines:
  default:
    - step:
        name: Run Tests
        script:
          - npm ci
          - npm test

Every push to any branch triggers the default pipeline. Branch-specific pipelines override the default for named branches.

Running Jest Tests

Basic setup

# bitbucket-pipelines.yml
image: node:20

pipelines:
  default:
    - step:
        name: Unit Tests
        script:
          - npm ci
          - npm test -- --coverage --coverageReporters=text-summary
        artifacts:
          - coverage/**

With test reporting

Bitbucket can display test results from JUnit XML format. Configure Jest to output JUnit:

npm install --save-dev jest-junit
- step:
    name: Unit Tests
    script:
      - npm ci
      - npx jest --ci --reporters=default --reporters=jest-junit
    artifacts:
      - test-results/**
      - coverage/**

Set environment variables for jest-junit:

- step:
    name: Unit Tests
    script:
      - export JEST_JUNIT_OUTPUT_DIR=test-results
      - export JEST_JUNIT_OUTPUT_NAME=junit.xml
      - npm ci
      - npx jest --ci --reporters=default --reporters=jest-junit

Caching node_modules

pipelines:
  default:
    - step:
        name: Unit Tests
        caches:
          - node
        script:
          - npm ci
          - npm test

Bitbucket has a built-in node cache definition that caches node_modules. This typically cuts install time by 50-80% on subsequent runs.

Custom cache definition:

definitions:
  caches:
    npm-cache:
      key:
        files:
          - package-lock.json
      path: node_modules

pipelines:
  default:
    - step:
        caches:
          - npm-cache
        script:
          - npm ci
          - npm test

Running pytest

image: python:3.12

pipelines:
  default:
    - step:
        name: Python Tests
        caches:
          - pip
        script:
          - pip install -r requirements.txt
          - pytest --junitxml=test-results/junit.xml -v
        artifacts:
          - test-results/**

With coverage

- step:
    name: Python Tests with Coverage
    script:
      - pip install -r requirements.txt
      - pytest --junitxml=test-results/junit.xml --cov=src --cov-report=xml:coverage.xml --cov-report=term
    artifacts:
      - test-results/**
      - coverage.xml

Running Playwright Tests

Playwright requires a browser environment. Use the official Playwright Docker image:

pipelines:
  default:
    - step:
        name: E2E Tests
        image: mcr.microsoft.com/playwright:v1.44.0-jammy
        script:
          - npm ci
          - npx playwright test
        artifacts:
          - playwright-report/**
          - test-results/**

With base URL configuration

- step:
    name: E2E Tests
    image: mcr.microsoft.com/playwright:v1.44.0-jammy
    script:
      - npm ci
      - BASE_URL=https://staging.yourapp.com npx playwright test
    artifacts:
      - playwright-report/**

Parallel Steps

Run test suites in parallel to reduce total pipeline time:

pipelines:
  default:
    - parallel:
        - step:
            name: Unit Tests
            script:
              - npm ci
              - npm run test:unit
        - step:
            name: Integration Tests
            script:
              - npm ci
              - npm run test:integration
        - step:
            name: Type Check
            script:
              - npm ci
              - npx tsc --noEmit
    - step:
        name: E2E Tests
        image: mcr.microsoft.com/playwright:v1.44.0-jammy
        script:
          - npm ci
          - npx playwright test

The parallel block runs all three steps simultaneously. The E2E step waits for all parallel steps to complete (Bitbucket executes stages sequentially).

Parallel test sharding

For large test suites, shard across parallel steps:

- parallel:
    - step:
        name: "Jest Shard 1/3"
        script:
          - npm ci
          - npx jest --shard=1/3 --ci
    - step:
        name: "Jest Shard 2/3"
        script:
          - npm ci
          - npx jest --shard=2/3 --ci
    - step:
        name: "Jest Shard 3/3"
        script:
          - npm ci
          - npx jest --shard=3/3 --ci

For Playwright:

- parallel:
    - step:
        name: "Playwright Shard 1/4"
        image: mcr.microsoft.com/playwright:v1.44.0-jammy
        script:
          - npm ci
          - npx playwright test --shard=1/4
    - step:
        name: "Playwright Shard 2/4"
        image: mcr.microsoft.com/playwright:v1.44.0-jammy
        script:
          - npm ci
          - npx playwright test --shard=2/4

Branch-Specific Pipelines

Different pipelines for different branches:

pipelines:
  default:
    - step:
        name: Quick Tests
        script:
          - npm ci
          - npm run test:unit

  branches:
    main:
      - step:
          name: Full Test Suite
          script:
            - npm ci
            - npm run test:unit
            - npm run test:integration
      - step:
          name: E2E Tests
          image: mcr.microsoft.com/playwright:v1.44.0-jammy
          script:
            - npm ci
            - npx playwright test

    'release/*':
      - step:
          name: Release Tests
          script:
            - npm ci
            - npm test
            - npm run test:e2e:staging

Pull request pipelines

pipelines:
  pull-requests:
    '**':
      - step:
          name: PR Tests
          script:
            - npm ci
            - npm test
          after-script:
            - pipe: atlassian/bitbucket-test-summary:1.0.0

Using Atlassian Pipes

Bitbucket Pipes are reusable pipeline components. Several are useful for testing workflows:

Test summary report

- step:
    script:
      - npm test
    after-script:
      - pipe: atlassian/bitbucket-test-summary:1.0.0
        variables:
          REPORT_PATHS: 'test-results/*.xml'

Slack notification on failure

- step:
    name: Tests
    script:
      - npm test
    after-script:
      - pipe: atlassian/slack-notify:2.1.0
        variables:
          WEBHOOK_URL: $SLACK_WEBHOOK_URL
          MESSAGE: "Tests failed on $BITBUCKET_BRANCH"
        condition:
          status: FAILED

Environment Variables and Secrets

Store secrets in Bitbucket repository settings under Repository settings → Repository variables:

- step:
    name: Integration Tests
    script:
      - npm ci
      - DATABASE_URL=$DATABASE_URL npm run test:integration

Variables marked as Secured are masked in logs. They're available to all steps by default.

Step-level variable overrides

- step:
    name: Staging Tests
    script:
      - npm test
    deployment: staging  # required for environment variables

Configure deployment environments in Deployments settings.

Docker Services for Integration Tests

Run a database alongside your tests using services:

- step:
    name: Integration Tests with Database
    services:
      - postgres
    script:
      - npm ci
      - DATABASE_URL=postgresql://test:test@localhost/testdb npm run test:integration

definitions:
  services:
    postgres:
      image: postgres:15
      variables:
        POSTGRES_USER: test
        POSTGRES_PASSWORD: test
        POSTGRES_DB: testdb

Multiple services

- step:
    services:
      - postgres
      - redis
    script:
      - npm run test:integration

definitions:
  services:
    postgres:
      image: postgres:15
      variables:
        POSTGRES_USER: test
        POSTGRES_PASSWORD: test
        POSTGRES_DB: testdb
    redis:
      image: redis:7

Artifacts Between Steps

Pass files between steps using artifacts:

pipelines:
  default:
    - step:
        name: Build
        script:
          - npm ci
          - npm run build
        artifacts:
          - dist/**

    - step:
        name: E2E Tests
        image: mcr.microsoft.com/playwright:v1.44.0-jammy
        script:
          - npm ci
          - npx playwright test  # dist/ is available from previous step

Artifacts from earlier steps are automatically available in later steps.

Jira Integration

Bitbucket Pipelines integrates with Jira to link builds to issues. When your commit message includes a Jira issue key (PROJ-123), Bitbucket links the build to that Jira issue automatically.

In Jira, developers see build status directly on their issues without switching tools.

Managing Pipeline Minutes

Bitbucket Pipelines charges by build minutes. Optimize to stay within your plan:

  1. Cache aggressively — use cache definitions for dependencies
  2. Skip unchanged paths — use condition clauses to skip steps when irrelevant files change
  3. Run heavy steps only on main — put expensive tests in branch-specific pipelines
  4. Use faster images — alpine-based images start faster than full OS images

Path-based conditions:

- step:
    name: Backend Tests
    condition:
      changesets:
        includePaths:
          - "backend/**"
          - "package.json"
    script:
      - npm run test:backend

Conclusion

Bitbucket Pipelines provides solid CI/CD capabilities with minimal setup for teams already using Bitbucket repositories. The YAML configuration is straightforward, Docker-based step isolation prevents environment conflicts, and the Atlassian integration keeps build status visible in Jira.

Start with the basic pipeline for your test framework, add caching to speed up subsequent runs, then layer in parallel steps for faster feedback on large test suites. The branch-specific pipeline support lets you run quick tests on feature branches and comprehensive suites only on main.

Read more

ScyllaDB Testing Guide: Cassandra Driver Compatibility, Shard-per-Core Testing & Performance Regression

ScyllaDB Testing Guide: Cassandra Driver Compatibility, Shard-per-Core Testing & Performance Regression

ScyllaDB delivers Cassandra-compatible APIs with a rewritten Seastar-based engine that achieves dramatically higher throughput. Testing ScyllaDB applications requires validating both Cassandra compatibility and ScyllaDB-specific behaviors like shard-per-core data distribution. This guide covers both angles. ScyllaDB Testing Landscape ScyllaDB is a drop-in replacement for Cassandra at the API level—which means

By HelpMeTest