Testing and code quality

The installation ships its own quality tooling, configured at the root. You can point all of it at plugin or theme code too.

Composer scripts

Command	Tool	Checks
`composer phpstan`	PHPStan	Static analysis of `src`, at level 5, excluding `src/Presentation`
`composer phpcs`	PHP_CodeSniffer	PSR-1, PSR-12 and PHP 8.2 compatibility
`composer phpcbf`, `composer fix`	PHP_CodeSniffer	Fixes what it can automatically
`composer phpmd`	PHPMD	Common code smells
`composer unit-test`	PHPUnit	The suite in `tests/`
`composer code-coverage`	PHPUnit	HTML coverage report in `coverage/`
`composer analyse`	All of the above	Static analysis, style, mess detection and tests, in order

Configuration lives in phpstan.neon.dist, phpcs.xml.dist, phpmd.xml and phpunit.xml.

Checking your own code

vendor/bin/phpcs --standard=phpcs.xml.dist extra/extensions/acme/hello/src
vendor/bin/phpcbf --standard=phpcs.xml.dist extra/extensions/acme/hello/src
vendor/bin/phpstan analyse --level=5 extra/extensions/acme/hello/src

Static analysis is particularly valuable for plugins: it catches a renamed core method or a changed signature before your users do, which is the most common way a plugin breaks on a new release.

Writing tests

The PHPUnit configuration bootstraps the application’s autoloader and runs the suite in tests/, with coverage measured over src/. For a plugin, test what you can isolate:

Test	How
Value objects and mappers	Plain unit tests, no container needed
API clients	A PSR-18 client double returning canned responses
Services	Construct with test doubles for the core services they inject
Command handlers	Doubles for repositories and the event dispatcher

Keep tests in your own package, with their own composer.json scripts, so they run without an Aikeedo installation.

tests/Unit/ContactMapperTest.php

<?php

declare(strict_types=1);

namespace Acme\Crm\Tests\Unit;

use Acme\Crm\ContactMapper;
use PHPUnit\Framework\TestCase;

class ContactMapperTest extends TestCase
{
    public function testMapsEmailAndName(): void
    {
        $contact = (new ContactMapper())->toContact($this->makeUser());

        $this->assertSame('dev@acme.test', $contact['email']);
    }
}

What automated tests won’t cover

Routes, settings pages, webhooks and payment flows need a running installation. Check them manually against a local install with DEBUG=true:

Install the extension into an installation that never had it.

Exercise every page and endpoint it adds.

Behave as a fresh installation would: no settings saved yet.

Deactivate and uninstall, and confirm nothing is left behind.

Read var/log afterwards.

Continuous integration

A minimal pipeline for a plugin repository:

.github/workflows/ci.yml

name: CI

on: [push, pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
      - run: composer install --no-interaction
      - run: vendor/bin/phpcs --standard=PSR12 src
      - run: vendor/bin/phpstan analyse --level=5 src
      - run: vendor/bin/phpunit

Pin the PHP version to the one Aikeedo requires, so incompatibilities surface in CI rather than on a customer’s server.

Get Started

Plugins

Extension Guides

Themes

Core Architecture

REST API

Testing and code quality

Composer scripts

Checking your own code

Writing tests

What automated tests won’t cover

Continuous integration

​Composer scripts

​Checking your own code

​Writing tests

​What automated tests won’t cover

​Continuous integration

​Related

Composer scripts

Checking your own code

Writing tests

What automated tests won’t cover

Continuous integration

Related