Агрегаты тестирования с PHPUnit и Laravel

Question

Я ищу несколько советов по тестированию агрегатных объектов с помощью PHPUnit и Laravel.

. В моем приложении есть три класса, которые составляют единое целое:

Condition "belongsTo" ConditionGroup
ConditionGroup "belongsTo" ConditionResult

Эти классы используются вместе, чтобы определить, является ли набор условий истинным или нет. Условия в группе условий представляют тест «И» (т. Е. Все условия должны иметь значение true для того, чтобы ConditionGroup возвращала true), а ConditionGroups в ConditionResult представляют тест «ИЛИ» (т. Е. Любая из ConditionGroups может возвращать true для возврата ConditionResult true)

Бессмысленно, чтобы Condition или ConditionGroup существовали самостоятельно, не будучи частью ConditionResult, и поэтому у меня есть класс ConditionManager с методом stati c 'create' для создания экземпляров всех трех классов и убедитесь, что они становятся связанными. Я также выкидываю пользовательские исключения, когда делаются попытки создания экземпляров Condition или ConditionGroup. (В конечном счете, это исключения PDOException, поскольку я гарантировал, что в миграциях эти поля должны иметь значение, т. Е. Они не являются «обнуляемыми»)

Моя проблема заключается в том, что когда я хочу проверить функциональность условия, я необходимо использовать ConditionManager для создания всех трех классов, а затем получить экземпляр Condition через отношения и протестировать функцию самостоятельно.

$conditionresult = ConditionManager::create($params);
$condition = $conditionresult->conditiongroups->first()->conditions->first();
//can now test Condition

Кажется, что когда я создаю тесты для Condition, я невольно , тестирование ConditionGroup и ConditionResult и так повторяющиеся тесты.

Какой будет наилучший подход? Что я делаю "хорошо" в мире тестирования? Некоторые другие вещи, которые я рассмотрел:

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

2. Забудьте о тестировании Condition и ConditionGroup и используйте тесты для ConditionManager, гарантирующие, что я тестирую каждый аспект. Не уверен, что мне это тоже нравится, поскольку это идет вразрез с «модульным тестированием».

Любая помощь приветствуется!

Answer 1

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

Если для А или В не имеет смысла существовать без C, то A, B и C вместе образуют единое целое. Это означает, что вы должны тестировать только классы A, B и C вместе.

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

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