Базовая структура Каталогов:

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

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

Одним из недостатков является то, что это затрудняет выпуск вашего производственного кода без сопровождающих его тестов. Хотя, если вы используете строгое именование условности это все еще может быть возможно. Например, я использовал ClassName.php, ClassNameUnitTest.php, и ClassNameIntegrationTest.php . Когда я хочу запустить все модульные тесты, есть набор, который ищет файлы, заканчивающиеся на UnitTest.php . Набор интеграционных тестов работает аналогично. Если бы я захотел, я мог бы использовать аналогичную технику, чтобы предотвратить выпуск тестов в производство.

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

Один тестовый класс на класс:

Это далеко не экспериментально для большинства программистов, но для меня это так. Я экспериментирую только с одним тестовым классом на каждый тестируемый класс. В прошлом у меня был целый каталог для каждого тестируемого класса, а затем у меня было несколько классов внутри этого каталога. Каждый тестовый класс настраивает тестируемый класс определенным образом, а затем у каждого из них есть несколько методов с другим утверждением. Но затем я начал замечать, что определенные условия, в которые я помещал эти объекты, имели нечто общее с другими условиями, в которые они попадали из других тестовых классов. С дублированием стало слишком сложно справиться, поэтому я начал создавать абстракции, чтобы удалить его. Тестовый код стал очень сложным для понимания и поддержки. Я понимал это, но не видел альтернативы, которая имела бы для меня смысл. Просто имея один тестовый класс на класс, казалось, что он не сможет протестировать почти достаточно ситуаций, не становящихся непреодолимыми, чтобы иметь весь этот тестовый код внутри одного тестового класса. Теперь у меня другой взгляд на это. Даже если бы я был прав, это огромное препятствие для других программистов и для меня, желающих писать и поддерживать тесты. Теперь я экспериментирую с тем, чтобы заставить себя проводить по одному тестовому классу на каждый тестируемый класс. Если я столкнусь со слишком многими вещами для тестирования в этом одном тестовом классе, я экспериментирую, рассматривая это как признак того, что класс тестирование делает слишком много, и его следует разбить на несколько классов. Для устранения дублирования я стараюсь придерживаться как можно более простых абстракций, которые позволяют всему существовать в одном читаемом тестовом классе.