Обычно юнит-тесты пишутся как можно более независимыми. Мы стараемся сделать их устойчивыми к изменениям окружения, порядка выполнения, стороннего кода и так далее. Цель юнит-тестирования это фиксирование поведения кода, находящегося в изоляции. Но в реальности бывает нужно проверять код только при соблюдении каких-либо внешних условий или предположений.

Подготовка

Как обычно, создаём пустой maven проект и добавляем к нему JUnit:

Помимо пустого проекта, нам ещё понадобится класс  GreatCircle из примера использования параметров.

Предусловия

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

Очевидно (а мы этого и добивались), что поведение метода LocalizedDateService.formatDate() зависит от текущей локали и, когда этот тест выполнит, допустим, албанец, тест провалится. Но нам и надо проверить только поведение для русского языка! Поэтому добавим к тесту предположение:

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

JUnit поддерживает assumeThat и assumeTrue. Остальные функции, аналогичные assert*, не поддерживаются.

Теории

Теории объединяют предусловия и параметризацию, позволяя писать обобщённые тесты.

Классическое юнит-тестирование основывается на примерах и частных случаях. Обычно тесты выражаются в форме «примера использования»: «если входной параметр — строка с числом n, то результат число равное n», «если входная строка null, то результат — выбрасывание исключения». Поскольку поведение обычно разное, то и на каждый проверяемый вариант поведения пишется отдельный тест.

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

Теории предлагают еще более общие тесты, которые можно выразить как «При определённых предположениях код всегда ведёт себя определённым образом». «Всегда» означает: «с любыми данными». Пример такого утверждения: «При возведении числа в целую чётную степень результат всегда будет положительным». «Возведение числа» — код, «Целая чётная степень» — предположение, «Всегда положительный» — проверяемый результат. В общем виде теории позволяют выразить предназначение и поведение кода.

Давайте немедленно проверим утверждение о чётных степенях:

В первую очередь, все классы, содержащие теории, должны исполняться с поддержкой теорий: @RunWith(Theories.class) . Во вторых, вместо объявления теста @Test , объявляется теория @Theory , содержащая предположения и собственно тест. Предположения ведут себя предсказуемо — если предположение проваливается, то для данного набора данных игнорируется.

И, наконец, самое главное — данные. Данные определяются с помощью аннотации @Datapoint и явно в тест не передаются. Вместо этого JUnit запускает тест на всех возможных комбинациях данных. Подстановка данных осуществляется по их типам, поэтому количество параметров может не совпадать с количеством данных.

Например, можно расширить наш тест, переписав его с double и int:

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

Один тип, разные значения

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

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

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

Данные, одинаковые по типу, но разные по смыслу, можно разделить вручную:

Аннотации @Latitudes и @Longitudes связывают значения для теста с их источниками:

Сами источники значений весьма просты — они возвращают массив значений, завёрнутых в PotentinalAssignment. Для создания PotentionalAssignment надо передать ему имя значения и собственно значение.

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

Исходный код примера доступен на github