CodeIgniter и Unit-тесты. Что использовать?

Question

[TheHorse]

Есть проект на CodeIgniter (4 Контроллера (3 из наследуются от главного), 4 модели (3 из них наследуются от главной), около 40 вьюшек, 8 хелперов ~ 5 000 написанного кода).

Стоит задача покрыть все это дело юнит-тестами, таким образом, чтобы можно было запустить все тесты один раз, и увидеть полный отчет.

В связи с чем вопросы:



1. Что использовать? Unit Test Class из CodeIgniter больше похож на assert, чем что-то нормальное. С ним я не смогу тестировать все одним запуском. С PHPUnit все усугубляется тем, что он не связан с CodeIgniter структурой и я не смогу просто инклудить какой-то класс потому, что не подтянутся все autoload, зависимости, прочие.



Контекст:

Mock я делать не могу, потому, что на БД все сильно завязано и важно знать об ошибках в БД, как об ошибках в входящих данных.



Также есть функции отправки милы, смс-ок. И это все участвует в бизнес-логике, что также хочется автоматически тестировать.

Comments

[Сергей Протько]

Так собственно в чем проблема использовать PHPUnit? Мануалов в сети много.

[TheHorse]

Когда есть класс, который нужно протестировать, никаких проблем нет, но когда есть множество классов, которые связаны с собой наследованием, и используют всякие хелперы и конфиги и маршрутизации… В общем, я из внешней среды, банально не могу вызвать хоть какой-то из методов своих классов, так чтоб он отработал не ругаясь на отсутствие библиотек и прочих файлов. Это ограничения самого фреймворка, и сама суть фреймворка. А PHPUnit предполагает, что такая возможность у меня есть.

Answer 1

[TheHorse]

Вопрос был не о том, что делать с бд и прочим, а об уровнях доступа и как получить доступ к тестируемому методу, а точнее ко всем тестируемым методам.

Придумал вот, что:
Для каждой модели и контроллера, внутри класса делаю метод test, и отдельный хелпер с набором тестов. В этом test просто запускаю все методы соответствующего хелпера (нужно еще подумать будет над синтаксисом), чтоб метод test был минимальным, а все тесты определялись исключительно в хелперах.
Потом, делаю один метод, для site.com/test, который запустит хоть через ajax все test для нужных контроллеров, которые запустят все тесты соответствующих моделей.

В итоге:
1. Открыв страницу я получу результаты всех unit-test-ов.
2. Минимальное влияние на тестируемый код (+1 метод во всех классах)
3. Нет надобности в каких-то дополнительных инструментах.

P. S. Прошу простить, вопрос скорее глупый, чем не глупый.

Answer 2

[pletinsky]

Если вы не можете сделать моки — то речь вообще не о юнит тестах и обычные фреймворки для юнит тестов вам могут не помочь. Юнит тесты это тесты на отдельные модули — обычно на методы класса в отрыви от внешнего окружения.
Не только от базы данных — а вообще от всех других классов.
И если так подходить к делу — то вам должно быть наплевать на то что юнит тесты чего то там не подтягивают.
Юнит тесты предполагают архитектурную готовность системы и обычно пишутся до кода в рамках TDD.

Если хотите сделать приложение стабильным — в вашем случае нужны behaviour тесты. Просто разворачивайте приложение как будто это делаете на продакшене — и тестируйте все его поведение в целом эмулируя действия пользователя на вебе.

Comments

[TheHorse]

Спасибо за ответ, надеюсь на альтернативные мнения и позиции по этому поводу, хотя скажу что у меня были такие опасения.

Answer 3

[Владимир Чернышев]

Попробуйте прикрутить Codeception от Davert насколько помню CI должно быть несложно прикрутить. Есть примеры для Kohana, ZF, Symfony, по аналогии должно быть несложно сделать для CI.

Comments

[TheHorse]

Спасибо, попробую.

[TheHorse]

Посмотрел Unit Module из Codeeception — все таже проблема, что и для PHPUnit, судя по example:
require_once 'PHPUnit/Framework/Assert/Functions.php';

[TheHorse]

Прошу прощения, не туда посмотрел… не туда и не так. Нужно копать детальней.

Answer 4

[pletinsky]

То есть можно конечно привязаться к разным уровням приложения в тестах — но в данном случая как я понимаю — вы не можете привязаться ни к чему — поэтому предлагаю привязаться к самому верхнему уровню из возможных, рассматривая внутренности приложения как блек бокс.
Все остальное очень зависит от делатей самого проекта — почему у вас там не получается оргинизовать подобие интеграционных тестов.

Comments

[pletinsky]

случайно написал новый пост вместо комментария на предыдущий. сорри.

[TheHorse]

Ну можно, да. Но крайне сложно, а я пытаюсь найти что-то, с чем мне не понадобится спускаться до основ маршрутизации и делать определенно уровня хаки и хуки.

[pletinsky]

Какая еще маршрутизация — это стандартные задачи, для которых вагон и маленькая тележка иструментов и библиотек.
Изучите тему получше.

[TheHorse]

Объясняю. Чтобы контролировать вход и выход к конкретной функции, мне нужно либо эмулировать HTTP запросы, что проблемно и недостаточно, либо разбирать весь CodeIgnitor от маршрутизации, чтобы контролировать все, что происходит перед тем как запустится нужная мне функция.
Что мне нужно изучить получше?

[pletinsky]

У вас пользователь продукта делает http запросы? Сомневаюсь.
У вас же обычное веб приложение? Я правильно понял?
То есть пользователь кликает по кнопкам на вебе и смотрит как меняется картинка.
Инструментов эмуляции его действий очень много. Один из крупнейших — Selenium.
Ниже даже вон предложили обертку вокруг этого продукта для php.

[pletinsky]

Получше изучить что такое BDD.

[Владимир Чернышев]

pletinsky, ниже не столько обёртка для Selenium (хотя и можно её в этом качестве использовать), сколько средство для эмуляции http-запросов из среды исполнения тестов.

[TheHorse]

pletinsky, не важно, что делает пользователь. Это не функциональное тестирование. Я говорил, о методе для реализации юнит-тестов. Да, обычное веб-приложение. Про Selenium знаю, и собираюсь использовать, но мне еще нужно и конкретные функции тестировать (unit-test) чего с селениумом у меня сделать не получится.

Что такое TDD/BDD я знаю.

[TheHorse]

Помиловать нельзя казнить.