On the Layout of Tests

Здесь, в приватном методе `prepare(),` у меня есть удобный конструктор объекта класса `Phrases.` Этот конструктор может быть полезен для других тестов, таких как `GreetingsTest.` Я не хочу копировать его из `PhrasesTest` в `GreetingsTest.` Вместо этого, я хочу поместить его где-то, где он может быть повторно использован. Это будет правильное место для него (`foo` - это пакет Java, к которому принадлежат все наши классы).

Статический метод `FooUtils.prepare()` теперь находится в утилитарном классе `FooUtils` (ужасный анти-паттерн!), который находится в пакете `foo.support`. Однако обратите внимание, что он не находится в пакете `foo`, а в подпакете, который не имеет аналога в блоке живого кода: здесь нет директории `src/main/java/foo/support.` Это ясное сообщение программисту, который встретит этот репозиторий через несколько лет: все классы, находящиеся в `foo.support`, принадлежат только к тестовому пайплайну и сами по себе не являются тестами.

## Test Prerequisites (Right Way)

Как вы знаете, утилитарные классы и приватные статические методы являются элементами императивного программирования. В объектно-ориентированном мире есть более эффективные альтернативы. В частности, JUnit5 предлагает довольно элегантные механизмы для создания предварительных условий тестирования: [расширения тестов](https://junit.org/junit5/docs/current/user-guide/#extensions-registration). Все, что нужно для выполнения тестового метода, мы предоставляем через его параметры, которые создаются расширениями, например:

```java
import org.junit.jupiter.api.extension.*;

class PhrasesExtension implements ParameterResolver { @Override public boolean supportsParameter( ParameterContext pctx, ExtensionContext ectx) { return pctx.getParameter().getType() == Phrases.class; } @Override public Object resolveParameter( ParameterContext pctx, ExtensionContext ectx) { Phrases p = new Phrases(); p.add("Hello, world!"); p.add("London is a capital of Great Britain"); return p; } } ```

Затем, тест будет выглядеть так:

```java
import org.junit.jupiter.api.extension.ExtendWith;

@ExtendWith(PhrasesExtension.class) class PhrasesTest { @Test void countsSimpleGreetings(Phrases p) { assertThat( "Total count of greetings", p.greetings().count(), equalTo(1) ); } } ```

Теперь тест и его предварительные требования находятся в двух разных местах и не так тесно связаны, как раньше. Более того, предварительные требования могут быть легко повторно использованы. Магическая аннотация `@ExtendWith` может быть применена к другим тестам. Реализация `PhrasesExtension` может стать умнее: она может начать обращать внимание не только на тип аргумента метода теста, но и на пользовательскую аннотацию, присоединенную к нему (так работает [`@TempDir`](https://junit.org/junit5/docs/5.4.1/api/org/junit/jupiter/api/io/TempDir.html)).

## Fake Objects (Best Way)

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

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

Решение заключается в использовании фальшивых объектов. Они находятся вместе с другими реальными объектами, но обладают специальным "фальшивым" поведением, например (Кстати, я не люблю фабрики, но в этом случае это приемлемо):

Затем тест будет выглядеть так:

Расположение репозитория будет выглядеть так:

Обратите внимание на тест `FactoryOfPhrasesTest.` Он тестирует "фальшивый" объект `FactoryOfPhrases`, который является частью коллекции живых классов. Фабрика фраз поставляется вместе со всеми остальными классами. Поэтому ее можно использовать другими проектами и не только в тестовых целях.

В заключение, как правило, я предлагаю поддерживать тестовые классы в чистоте: там должны находиться только тестовые методы. Никаких атрибутов и, конечно же, никаких статических приватных методов. Все, что является предпосылкой, должно быть "фейковым" объектом.

## Integration Tests

В мире Maven существуют классы модульного тестирования (с суффиксом `Test`) и классы интеграционного тестирования (с суффиксом `ITCase`). Разница между ними огромна. Оба они компилируются в фазе `test-compile` с использованием плагина `maven-compiler-plugin`, но не выполняются вместе. Вместо этого модульные тесты выполняются в фазе `test`. Сборка сразу же завершается с ошибкой, если не пройден хотя бы один модульный тест. Это довольно прямолинейный подход, аналогичный другим средствам автоматизации сборки.

Интеграционные тесты выполняются в четыре этапа (это названия фаз Maven):

Сначала ресурсы, необходимые для интеграционного тестирования, получаются на этапе `pre-integration-test`. Например, может быть запущен тестовый экземпляр базы данных MySQL. Затем тесты с использованием `ITCase` выполняются на этапе «integration-test». Результат их выполнения на данный момент игнорируется, но записывается в файл. Затем ресурсы освобождаются на этапе `post-integration-test`. Например, сервер MySQL выключается. Наконец, на этапе `verify` результаты тестов проверяются, и сборка не проходит, если некоторые из них не являются успешными.

Я храню файлы `ITCase` вместе с файлами `Test` только тогда, когда они являются интеграционными тестами для конкретных живых классов. Очень часто они ими не являются - вот почему они и называются интеграционными тестами. Они могут интегрировать и тестировать несколько классов вместе. В этом случае я помещаю их в отдельный пакет и даю им произвольные имена, которые не совпадают с именами живых классов.