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 --ci
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: Checkout11 uses: actions/checkout@v312 13 - name: Setup PHP14 uses: shivammathur/setup-php@v215 with:16 php-version: 8.217 tools: composer:v218 coverage: xdebug19 20 - name: Install Dependencies21 run: composer install --no-interaction --prefer-dist --optimize-autoloader22 23 - name: Tests24 run: ./vendor/bin/pest --ci
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_requests10 - push11 cache:12 key:13 files:14 - composer.lock15 policy: pull-push16 image: composer:217 script:18 - composer install --no-interaction --prefer-dist --optimize-autoloader19 20tests:21 stage: test22 only:23 refs:24 - merge_requests25 - push26 cache:27 key:28 files:29 - composer.lock30 policy: pull31 image: php:8.232 script:33 - ./vendor/bin/pest --ci
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 Bitbucket 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-autoloader10 - ./vendor/bin/pest11 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: 810# - redis:11 12# Build all commits13on:14 push:15 branches: .*16 17pipeline:18 - name: Setup19 cmd: |20 cp -v .env.example .env21 composer install --no-interaction --prefer-dist --optimize-autoloader22 php artisan key:generate23 24 - name: Compile Assets25 cmd: |26 npm ci --no-audit27 npm run build28 29 - name: Test30 cmd: pest
In addition to handling Composer and NPM caches, Chipper CI automatically adds vendor/bin
to your PATH, so simply running the pest --ci
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 →