Разрешите представить Вам перевод статьи Johannes Schmitt Automated Code Reviews for PHP. Лично мне она помогла несколько иначе взглянуть на процесс разработки и тестирования своих приложений. А оригинальный подход автора к тестированию, как минимум, заслуживает внимания.
Если вам тоже интересно, добро пожаловать под кат.

С тех пор как появился Trevis, вы можете в мгновение ока внедрить непрерывную интеграцию во все свои PHP-проекты. Это помогает не только улучшить качество кода, но и существенно упрощает поддержку библиотек, предоставляя информацию о сборке прямо в запрос на обновление(pull request) и, тем самым, уменьшает время получения обратной связи. Travis очень хорош, но, как и другие инструменты тестирования, страдает от наследственной болезни — что бы что-то сделать ему нужны тесты. Готовь биться об заклад, что у вас нет ни одного проекта честно покрытого тестами на 100% или, даже, близко к этому. Это я еще надеюсь, что тесты вы пишите.

Как вам возможно известно, я поддерживаю значительное число плагинов(bundles) для Symfony2 и самостоятельных PHP-библиотек. И благодаря сообществу(спасибо ребята, так держать) я постоянно получаю запросы на обновление в свои репозитории. Некоторые из запросов совершенно бесполезные, некоторые заслуживают внимания, некоторые можно добавлять в основную ветку. Но как бы тщательно не проверялся запрос, время от времени случается так, что добавляется то что не работает или работает, но не всегда.

Пару месяцев назад я попытался изменить эту ситуацию, идея была довольно простой: создать систему которая проверяет код запроса на обновление и дает обратную связь. Я довольно быстро сделал прототип и добавил в него пару простых проверок. Затем, захотел добавить более сложны, например, проверку может ли метод быть вызван. Что бы понять пользу такой проверки, посмотрите на следующий пример:

<?php

class UserProvider
{
    /** @return User|null */
    public function loadUser($username) { /** ... */ }

    public function refreshUser(User $user)
    {
        if (null === $user = $this->loadUser($user->getUsername())) {
            throw new RuntimeException(
                sprintf('User "%s" was not found.', $user->getUsername()));
        }

        return $user;
    }
}

И так, метод refreshUser получает объект класса User при помощи метода loadUser и возвращает этот объект. А если объект не найден, то бросает исключение. Вроде бы все просто, но так ли это на самом деле? И если уж я об этом спрашиваю, то видимо нет и многие из вас уже заметили ошибку. Внутри блока if $user равен null и мы не можем вызвать у него метод getUserName. Что бы находить такого рода ошибки я испробовал несколько простых решений, но довольно быстро становилось очевидно что они работают только в очень специфичных случаях. Мне было нужно что-нибудь получше.

Type Inference of PHP Code

Я потратил довольно много времени вникая в концепции потока данных, потока управления и абстрактной интерпретации. Что само по себе выглядит довольно сложно и выходит за рамки этой статьи. Но позвольте мне привести всего несколько примеров и дать вам общее представление об этих концепциях.

Анализ потока управления(Control Flow Analysis)

Анализ этого потока позволяет определить в каком порядке будут выполняться различные блоки вашего кода.

<?php

function fooBar($i) {
    if ($i > 0) {
        echo 'foo';
    } else {
        echo 'bar';
    }
}

Для этого кода поток управления будет выглядеть так:

Мы начинаем в if, затем двигаемся к «foor» или «bar» и, наконец, выходим. Само по себе нам это вряд ли чем-то поможет, но это послужит основой для следующего шага.

Анализ потока данных(Data Flow Analysis)

Анализ потока данных позволяет определить как изменяется контекст выполнения пока мы движемся по схеме которую определили в анализе потока управления.

<?php

$x = null; // $x здесь null.

if ($y) {
    $x = new DateTime();
    $x->format(); // тут все хорошо, мы ведь знаем что $x это экземпляр DateTime
} else {
    $x = 0;
}

$x->format(); // $x экземпляр DateTime или число "integer", в зависимости от этого
                    // метод может быть вызван а может и нет

Не зная порядок выполнения кода, мы может заключить только то, что $x может быть null, число или DateTime. Но нам это не поможет выяснить может ли быть вызван метод format.

Абстрактная интерпретация(Abstract Interpretation)

Для нашего случая эта концепция сводится к вопросу «Какие предположения мы можем сделать, если знаем результат условного выражения?». Давайте взглянем на другой пример:

<?php

class Foo
{
    private $logger;

    public function __construct(Logger $logger = null)
    {
        $this->logger = $logger;
    }

    public function doSth()
    {
        if (null !== $this->logger) {
            $this->logger->log('doing sth');
        }
    }
}

В данном случае «условным выражением» будет null !== $this->logger. Если это условие истинно, то наш вопрос можно перефразировать так: «Если выражение null !== $this->logger истинно, то какое предположение можно сделать на счет $this->logger?» Как мы уже выяснили, $this->logger может быть null или Logger. Но благодаря абстрактной интерпретации мы можем быть уверены что внутри блока «if» $this->logger всегда будет экземпляром Logger, следовательно, метод может быть вызван.

Автоматическая система проверки

Какой от всего этого толк, спросите вы. В начале статьи я сказал, что моей целью было создание автоматической системы проверки кода. И я думаю что сейчас она готова для широкого использования и обсуждения. Я протестировал своей системой ведущие PHP библиотеки, такие как, Zend Framework 2, Symfony2, Doctrine, Propel и многие другие. Она содержит более 100 правил проверки, которые вы можете использовать и конфигурировать. Если у вас есть PHP-проект на Github вы можете легко попробовать. Просто залогинтесь http://jmsyst.com/automated-code-reviews и выберете нужный репозиторий. А если не понравиться, можете выключить в любое время.

Если теперь кто-то скажет, что PHP-программисты не слишком серьезно относятся к качеству кода, отправляйте их их ко мне.

Автоматическая проверка кода для PHP