Структура файловой системы / каталога для модульных и функциональных тестов с PHPUnit - PullRequest
Новая
       14

Структура файловой системы / каталога для модульных и функциональных тестов с PHPUnit

5 голосов
/ 31 октября 2011

Мне нужно добавить интеграционные тесты в мой набор тестов. Хотя имя PHPUnit, я обнаружил, что здесь есть много поддержки для запуска не модульных тестов. Мой макет примерно такой: 

<root>
    lib/
        Foo/
            Component.php
    tests/
        lib/
            Foo/
                ComponentTest.php
        resources/
            fixtures/

Есть (как я понимаю) три способа добавления тестов уровня выше единицы:

Добавление параллельной структуры 

<root>
    tests/
        unit/
            lib/
                Foo/
                    ComponentTest.php
        integration/
            lib/
                Foo/
                    ComponentTest.php
        resources/
            fixtures/

Это должно сработать, за исключением того, что теперь нет класса 1: 1: класс тестовых отношений, который может (и, вероятно, может) запутать Netbeans.

Добавление <root>/tests/lib/Foo/ComponentIntegrationTest.php

Имеет ту же проблему, что и выше, с меньшим количеством каталогов.

Добавление тестов к существующему классу тестов с пометкой @group integration

Это сохраняет соотношение 1: 1, но значительно усложняет набор тестов. Кроме того, поскольку SUT нужно будет вызывать в изменяющейся среде, я не могу просто повторно использовать _setup () из модульных тестов.

Идеи

1 Ответ

6 голосов
/ 01 ноября 2011

Модульные тесты используются для тестирования отдельного блока (класса) в изоляции. Интеграционные тесты предназначены для тестирования нескольких устройств вместе. Таким образом, вы, вероятно, не будете иметь соотношение 1: 1 между классами и интеграционными тестами, к которым они принадлежат.

Я бы создал отдельную структуру каталогов - возможно, даже отдельный проект - для размещения интеграционных тестов. NetBeans не сможет открыть «тест», к которому принадлежит класс, потому что он будет принадлежать нескольким тестам, но он будет продолжать открывать свой соответствующий модульный тест.

У нас есть отдельный проект для наших интеграционных тестов (называемый тестами работоспособности до моего приезда) с использованием Selenium, и он пока работает достаточно хорошо.

Обновление

Макет каталога для наших интеграционных тестов довольно прост: один каталог на сайт. У нас есть единая кодовая база для сайта, и мы используем представления, чтобы позволить отдельным сайтам переопределять макет (больше, чем просто скиннинг). Мы не потратили столько времени на эти тесты, как хотелось бы. Мы используем Selenium для запуска тестов после отправки сайтов на промежуточный сервер. У меня еще не было возможности подключить их к нашему серверу непрерывной интеграции (Jenkins), но это было бы идеально.

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

src/
    Model/
        Cart.php
    ...
tests/
    unit/
        phpunit.xml
        bootstrap.php
        Model/
            CartTest.php
        ...
    integration/
        account/
            login/
            register/
            subscriptions/
        products/
            listing/
            details/
            search/
        cart/
            shop/
            checkout/
...