2 minute read
18 Jan 2016
Tests are run automatically by GitLab.
To run the tests locally, you need:
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.
When adding the interpreter it should automatically detect the PHP executable path, if not, you’ll have to manually locate it.
Navigate to Settings / Language & Frameworks / PHP / PHPUnit and select phpunit.phar from the vendors folder in your SiteStacker installation.
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)
Set the Interpreter options config to
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:
- 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)
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
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).
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
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 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 (
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
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.
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).