Download the PHP package ikvasnica/phpstan-clean-test without Composer

PHPStan Clean Test rules

• PHPStan
• PHPStan-PHPUnit extension

This extension provides highly opinionated and strict rules for test cases for the PHPStan static analysis tool.

Installation

Run

Usage

All of the rules provided by this library are included in rules.neon.

When you are using phpstan/extension-installer, rules.neon will be automatically included.

Otherwise you need to include rules.neon in your phpstan.neon:

Rules

This package provides the following rules for use with phpstan/phpstan:

• ikvasnica\PHPStan\Rules\UnitExtendsFromTestCaseRule
• ikvasnica\PHPStan\Rules\DisallowSetupAndConstructorRule
• ikvasnica\PHPStan\Rules\AssertSameOverAssertEqualsRule
• ikvasnica\PHPStan\Rules\StaticAssertOverThisAndStaticRule
• ikvasnica\PHPStan\Rules\NoNullableArgumentRule

UnitExtendsFromTestCaseRule

This rule forces you to extend only from allowed classes in unit tests (default: PHPUnit\Framework\TestCase).

Why:

1. It prevents developers i.e. from using a dependency injection container in unit tests ($this->getContainer()) and other tools from integration/functional tests.
2. You should extend only from a class when a child class satisfies the "is a" relationship. That said, if you need only a subset of a parent's functionality, you should use composition over inheritance (i.e. by traits or helpers).

:x:

:white_check_mark:

Defaults

• By default, this rule detects unit tests by checking the namespace (it must contain the string Unit) and the class name ending (it must end with the string Test).
• The following class is allowed to be extended: PHPUnit\Framework\TestCase

Allowing classes to be extended

If you want to allow additional classes to be extended, you can add it to the classesAllowedToBeExtendedInTests parameter to a list of class names.

Detecting unit tests namespace

If you want to change the namespace string check described above, you can set your own string to be checked in the unitTestNamespaceContainsString parameter.

DisallowSetupAndConstructorRule

Neither of methods __construct nor setUp can be declared in a unit test.

Why: Each test scenario should create its dependencies on its own. Method setUp is useful for setting up i.e. database transaction in a functional test. In a unit test, you should put all the preparation into a testing method or a data provider itself. It increases readability and clearly shows the code intention.

Detecting unit tests namespace

If you want to change the namespace string check described above, you can set your own string to be checked in the unitTestNamespaceContainsString parameter.

Allowing setUp() method

If you really want to use the setUp() method, you can whitelist it by setting the parameter allowSetupInUnitTests to true.

:x:

:white_check_mark:

AssertSameOverAssertEqualsRule

Calling assertEquals in tests is forbidden in favor of assertSame.

Why: When using assertEquals, data types are not considered. On the other hand, assertSame checks whether two variables are of the same type and references the same object. Therefore, assertEquals can be valid when comparing objects or arrays, but not scalar values.

Using assertEquals with scalar values might lead to an unexpected behaviour (e.g. assertEquals(null, '') evaluates to true, whereas assertSame(null, '') evaluates to false).

:x:

:white_check_mark:

StaticAssertOverThisAndStaticRule

Calling $this->assert*, self::assert* or static::assert* in tests is forbidden in favor of PHPUnit\Framework\Assert::assert*.

Why: When you use PHPUnit, your test cases extend from \PHPUnit\Framework\TestCase. Assert methods are declared as static there, therefore it does not make sense to call them dynamically. Using static::assert* is discouraged, because it is a misuse of inheritance and assertion methods are more like a helper's methods.

:x:

:white_check_mark:

NoNullableArgumentRule

Nullable arguments and arguments with no type passed to test methods from data providers are forbidden.

Why: A nullable argument from a data provider is a code smell. Usually it means that you test two different scenarios in one test. You should divide the test into two scenarios, i.e. one for testing valid data input and one for invalid data when an exception is expected to be thrown.

:x:

:white_check_mark: