2 minute read 18 Jan 2016

Tests are run automatically by GitLab.

To run the tests locally, you need:

Running Tests

Configure PhpStorm to run unit tests

Set the PHP interpreter

Navigate to Settings / Language & Frameworks / PHP. If you do not have an interpreter selected, either select or add a new one.

Settings

When adding the interpreter it should automatically detect the PHP executable path, if not, you’ll have to manually locate it.

Interpreters

PHPUnit Configuration

Navigate to Settings / Language & Frameworks / PHP / PHPUnit and select phpunit.phar from the vendors folder in your SiteStacker installation.

PHPUnit Path

Open the Run/Debug Configurations window by using the dropdown in your toolbar. The position might differ from the one you see here (Creating and Editing Run/Debug Configurations)

Edit Configurations Button

Set the Interpreter options config to PATH_TO_YOUR_SITESTACKER_INSTALLATION/cakeunit-phpstorm.php

Edit Configurations Options

SiteStacker is now set up and ready to run unit testing.

Run unit tests from PhpStorm

From the project tree you either run tests for a single component by right clicking a component (eg. Contributions), or you can run the tests for all components by right clicking the components folder. You have 3 options when running tests:

  • Run
  • Debug (it enables XDebug and you’ll be able to debug your code while testing)
  • Run with Coverage (will analyze code coverage for the tests you’re running)

Run Tests

When running the tests you will see the progress in the panel below. From there you’ll have the option to re-run all tests or re-run only the failed tests

Test Results

After running a test with coverage you will see what parts of your covered and which were not. This will be indicated by a yellow line (for covered code) or a red line (for uncovered code).

Coverage

Running from command line

You can run tests using the cake test command, e.g.:

App/Console/cake test core AllConfigure --debug

Don’t forget to use the --debug flag.

Writing Tests

For comprehensive information on how to write tests see Testing in the CakePHP 2.x Cookbook.

Remember: tests should be simple and at the point, so that anyone can understand and change them when needed.

Continuous Integration

Continuous Integration is enabled in GitLab so tests run automatically after every push.

To enable CI, a .gitlab-ci.yml file needs to exist in the root of the project, specifying the jobs that will run. An example file looks like this:

Contributions:
  script:
  - App/Console/cake test Contributions AllContributions --debug

PaymentProcessors:
  script:
  - App/Console/cake test PaymentProcessors PaymentProcessor --debug
  - App/Console/cake test PaymentProcessors PaymentProcessorTransaction --debug


# DON'T EDIT BELOW THIS LINE

before_script:
- prepare.sh

variables:
  # Configure mysql service (https://hub.docker.com/_/mysql/)
  MYSQL_DATABASE: "sitestacker-test"
  MYSQL_ALLOW_EMPTY_PASSWORD: "1"

This example creates two jobs (Contributions and PaymentProcessors), each one using the App/Console/cake test command to run tests. Everything below these lines is required and can be ignored. You can specify as many jobs as you need, which can run one or more shell scripts.

.gitlab-ci.yml best practices

TODO

This section documents best practices for writing jobs in a .gitlab-ci.yml file and running scripts inside these jobs. This is a work in progress, taking into account that each job and script per job has a significant overhead on the build time, so fewer jobs and a single script per job looks to be the way to go. But we’re not sure yet how to group the jobs.

Skipping builds

If your commit message contains [ci skip] or [skip ci], the builds will be skipped (http://doc.gitlab.com/ce/ci/yaml/README.html#skipping-builds).