Continuous Integration

Up until now, we have only discussed running tests from the command line on your local machine. But, you can also run your tests from a CI platform of your choice. As pestphp/pest is included in your Composer development dependencies, you can easily execute the vendor/bin/pest command within your CI platform's deployment pipeline.

Example With GitHub Actions

If your application uses GitHub Actions as its CI platform, the following guidelines will assist you in configuring Pest so that your application is automatically tested when someone pushes a commit to your GitHub repository.

To get started, create a tests.yml file within the your-project/.github/workflows directory. The file should have the following contents:

1name: Tests
2 
3on: ['push', 'pull_request']
4 
5jobs:
6 ci:
7 runs-on: ubuntu-latest
8 
9 steps:
10 - name: Checkout
11 uses: actions/checkout@v3
12 
13 - name: Setup PHP
14 uses: shivammathur/setup-php@v2
15 with:
16 php-version: 8.2
17 tools: composer:v2
18 coverage: xdebug
19 
20 - name: Install Dependencies
21 run: composer install --no-interaction --prefer-dist --optimize-autoloader
22 
23 - name: Tests
24 run: ./vendor/bin/pest

Naturally, you may customize the script above according to your requirements. For example, you may need to set up a database if your tests require one.

Once you have created your tests.yml file, commit and push the tests.yml file so GitHub Actions can run your tests. Keep in mind that once you make this commit, your test suite will execute on all new pull requests and commits.

Example With GitLab CI/CD Pipelines

If your application uses GitLab CI/CD Pipelines as its CI platform, the following guidelines will assist you in configuring Pest so that your application is automatically tested when someone pushes a commit to your GitLab repository.

To get started, add the following configuration to your .gitlab-ci.yml file. The file should have the following contents:

1stages:
2 - build
3 - test
4 
5build:vendors:
6 stage: build
7 only:
8 refs:
9 - merge_requests
10 - push
11 cache:
12 key:
13 files:
14 - composer.lock
15 policy: pull-push
16 image: composer:2
17 script:
18 - composer install --no-interaction --prefer-dist --optimize-autoloader
19 
20tests:
21 stage: test
22 only:
23 refs:
24 - merge_requests
25 - push
26 cache:
27 key:
28 files:
29 - composer.lock
30 policy: pull
31 image: php:8.2
32 script:
33 - ./vendor/bin/pest

Naturally, you may customize the script above according to your requirements. For example, you may need to set up a database if your tests require one.

Once you have created your .gitlab-ci.yml file, commit and push the .gitlab-ci.yml file so Gitlab CI/CD Pipelines can run your tests. Keep in mind that once you make this commit, your test suite will execute on all new merge requests and commits.

Example with Bitbucket Pipelines

If your application uses Bitbucket CI/CD Pipelines as its CI platform, the following guidelines will assist you in configuring Pest so that your application is automatically tested when someone pushes a commit to your GitLab repository.

To get started, add the following configuration to your bitbucket-pipelines.yml file. The file should have the following contents:

1image: composer:2
2 
3pipelines:
4 default:
5 - parallel:
6 - step:
7 name: Test
8 script:
9 - composer install --no-interaction --prefer-dist --optimize-autoloader
10 - ./vendor/bin/pest
11 caches:
12 - composer

Naturally, you may customize the script above according to your requirements. For example, you may need to set up a database if your tests require one.

Once you have created your bitbucket-pipelines.yml file, commit and push the bitbucket-pipelines.yml file so Bitbucket Pipelines can run your tests. Keep in mind that once you make this commit, your test suite will execute on all new pull requests and commits.

Example with Chipper CI

If your application uses Chipper CI as its CI platform, the following guidelines will assist you in configuring Pest so that your application is automatically tested when someone pushes a commit to your git repository.

To get started, add the following configuration to your .chipperci.yml file. The file should have the following contents:

1version: 1
2 
3environment:
4 php: 8.2
5 node: 16
6 
7# Optional services
8services:
9# - mysql: 8
10# - redis:
11 
12# Build all commits
13on:
14 push:
15 branches: .*
16 
17pipeline:
18 - name: Setup
19 cmd: |
20 cp -v .env.example .env
21 composer install --no-interaction --prefer-dist --optimize-autoloader
22 php artisan key:generate
23 
24 - name: Compile Assets
25 cmd: |
26 npm ci --no-audit
27 npm run build
28 
29 - name: Test
30 cmd: pest

In addition to handling Composer and NPM caches, Chipper CI automatically adds vendor/bin to your PATH, so simply running the pest command will work when running tests.

Naturally, you may customize the scripts above according to your requirements. For example, you may need to define a database service if your tests require one.

Once you have created your .chipperci.yml file, commit and push the .chipperci.yml file so Chipper CI can run your tests. Keep in mind that once you make this commit, your test suite will execute on all new commits.


Great job setting up Continuous Integration for your project to ensure codebase stability! Now, let's take a deeper dive into Pest's concepts by exploring it's test configuration capabilities: Configuring Pest →