Есть ли какая-либо причина не держать модульные тесты PHP в тестируемом классе?

Question

Есть ли какая-либо причина не держать модульные тесты PHP в тестируемом классе?

1

Стандартная практика тестирования модулей PHP в таких рамках, как PHPUnit и PHPSpec, по-видимому, заключается в том, чтобы сохранить тестовые примеры в отдельной директории вдали от тестируемых классов, например:

FoobarApp
├── Models
│   ├── SomeModel
├── Tests
│   ├── SomeModelTest

Лично я считаю более ясным и более полезным поставить каждый тест рядом с классом, который он тестирует, в том же каталоге, как это:

FoobarApp
├── Models
│   ├── SomeModel
│   └── SomeModelTest

Мой вопрос: есть ли причина не использовать это альтернативное размещение? Это просто проблема предпочтений разработчиков?

Hugh Grigg 葛修远 07 нояб. 2015, в 13:43

Источник

3

Что делать, если вы хотите развернуть (то есть вам не нужны тестовые классы). Разве не было бы легче развернуть без каталога / Tests вместо того, чтобы выяснить, что выбрать для распределения по разным каталогам? Также смешивание тестовых классов с «нормальными» классами создает неразрывный беспорядок в приличном проекте.
PeeHaa 07 нояб. 2015, в 11:53
0

@PeeHaa Я считал, что тестовые классы также будут развернуты в большинстве процессов развертывания, но я не вижу, что это обязательно проблема? Я совсем не согласен с точкой зрения «неразберихи», есть ли у вас что-нибудь, чтобы это подтвердить? Напротив, сохранение тестов в тестируемом классе значительно облегчает их разработку и поддержку, на мой взгляд.
Hugh Grigg 葛修远 07 нояб. 2015, в 12:41

Теги:

php

unit-testing

1 ответ

Ещё вопросы

Что делать, если вы хотите развернуть (то есть вам не нужны тестовые классы). Разве не было бы легче развернуть без каталога / Tests вместо того, чтобы выяснить, что выбрать для распределения по разным каталогам? Также смешивание тестовых классов с «нормальными» классами создает неразрывный беспорядок в приличном проекте.
@PeeHaa Я считал, что тестовые классы также будут развернуты в большинстве процессов развертывания, но я не вижу, что это обязательно проблема? Я совсем не согласен с точкой зрения «неразберихи», есть ли у вас что-нибудь, чтобы это подтвердить? Напротив, сохранение тестов в тестируемом классе значительно облегчает их разработку и поддержку, на мой взгляд.

mark · Accepted Answer · 2015-11-08T16-52-00.000Z

Это просто проблема предпочтений разработчиков?

В принципе, да.

Он начинался как предпочтение и довольно распространен в языках ООП, например, также на Java, который обычно разделяется.

Другие считают, что есть больше преимуществ, связанных с этими испытаниями:

не загромождайте дерево реализации
имея один тестовый класс для одного класса реализации, он просто обычен, но нет правила. Если это имеет смысл, может быть уместно иметь несколько тестовых классов для вашего класса реализации. Теперь учтите это, если все они также находятся в вашем src/ tree.
чистый для развертывания. Никто не нуждается в тестовых случаях в производстве; наличие их в отдельном каталоге делает его глупым - легко исключить их.
более легкое разделение при поиске по базе кода. Большую часть времени я не интересуюсь поиском тестов

Вы можете принять то, что большинство разработчиков приучены или катят свое дело, никого не останавливает или не заставляет вас. Но как только вы работаете с другими (команды @work, OSS), вы обнаружите, что большинство их разделяет.

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

Например:

Я не поклонник PSR-2:

отдельный { по классам/методам? нет
4 пробела? Я предпочитаю 2.

Однако вам не нравится стандарт: есть преимущества при сотрудничестве, мышление в команде. Таким образом, я перешел на PSR-2 во всех своих проектах, хотя лично мне это не нравилось.

Там нет места для личного эго при сотрудничестве с другими. Это не значит, что ты должен подчиниться всему. Вы сами решаете, насколько хорошо вы играете как часть более широкой картины ;-)

Это достойный и правильный ответ, однако, учитывая тот факт, что вы допускаете использование двух пробелов, я просто не могу это высказать. Это просто ужасно: P
Я предпочитаю правое поле в 80 символов, и с четырьмя пробелами это становится очень сложно. Я также люблю работать с вертикальными разбиениями, и поэтому наличие 80–100 символов помогает вывести их на экран без достаточного места.