тестирование классов-наследников каркаса (ConcreteAction и т.п.)

[robocomp]

тестирование классов-наследников каркаса (ConcreteAction и т.п.)

Здравствуйте. Недавно закончил первую систему, где на 100% покрыл тестами классы, описывающие предметную область.
В разработке использовал нане мутировавшую mojavi 3.0 phpUnit2, smarty (вроде всё)

при этом я совсем не покрывал автоматическими модульными тестами классы, которые наследовали классам каркаса (ListAction -> Action), в которых, прямо скажем, тоже кое-какая логика имеется.
Скажите пож-та, уважаемые коллеги, использующие ТДД, вы покрываете тестами подобные классы? В каком случае?

 

[pachanga]

Все зависит от конкретного случая... Обычно тестирование иерархии наследования приводит к тому, что появляется схожая параллельная иерархия наследования тестов. И зачастую получается так, что после рефакторинга иерархия превращается в композицию.

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

Сказать что-то более конкретное можно, только оценив код...

P.S. поздравляю тебя со 100% тестовым покрытием, так уж и 100%? Кстати, в CVS версии WACT появилась возможность увидеть визуально степень покрытия тестами кода при помощи xdebug2 и spikephpcoverage - очень занимательно.

 

[syfisher]

К сожалению Mojavi 3.0 смотрел слишком давно, что-то конкретное сказать не могу. Тесты на такие классы обычно находятся где-то на границе функциональных и модульных.

Лично мой опыт говорит следующее:
1) Изолирование при помощи мок-объектов уже не используют.
2) Тестируются только внешние проявления, то есть только black-box testing.
3) Тестировать только базовые классы Action, дочерние классы, которые конфигурируют базовые - только через приемочные тесты (обычно при помощи Selenium).
4) Если дочерний класс содержит сложную логику, то этот кусок я выделяю в отдельную команду, тестирую ее, а конечную связку - только при помощи приемочных тестов.

То есть формируем так называемый контекст, пропускаем этот контекст через команду, смотрим, что стало к контекстом.

Кстати, необходимость тестировать команды повлияло на то, что в Limb фаза рендеринга ушла в отдельный фильтр, появилась иерархия View-классов и т.д.

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

В остальном - только исходя из реальной ситуации.

 

[robocomp]

понятно, всем спасибо. Я, в общем-то, так и думал. Про грань модульных и функциональных, при написании таких тестов.

P.S. поздравляю тебя со 100% тестовым покрытием, так уж и 100%?

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