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 testEvery 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-junitCaching node_modules
pipelines:
default:
- step:
name: Unit Tests
caches:
- node
script:
- npm ci
- npm testBitbucket 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 testRunning 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.xmlRunning 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 testThe 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 --ciFor 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/4Branch-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:stagingPull request pipelines
pipelines:
pull-requests:
'**':
- step:
name: PR Tests
script:
- npm ci
- npm test
after-script:
- pipe: atlassian/bitbucket-test-summary:1.0.0Using 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: FAILEDEnvironment 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:integrationVariables 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 variablesConfigure 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: testdbMultiple 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:7Artifacts 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 stepArtifacts 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:
- Cache aggressively — use cache definitions for dependencies
- Skip unchanged paths — use
conditionclauses to skip steps when irrelevant files change - Run heavy steps only on main — put expensive tests in branch-specific pipelines
- 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:backendConclusion
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.