Как не надо писать модульные тесты

Хороший юнит-тест написать легко, плохой — ещё проще.

Плохой юнит тест ничего не проверяет. То есть конечно что-то с чем-то сравнивается, какое-то поведение проверяется, но…стоит поменять что-нибудь в тесте, как ничего не происходит. Я уже писал, что признаком проблемы с юнит-тестом можно считать невозможность придумать условия, в которых он не пройдёт.
Плохой юнит тест что-то проверяет, да не то, что надо. Это пересекается с предыдущей проблемой, но, всё же, это другая проблема. Положим, что вы тестируете код, который делает запрос к базе данных и фильтрует результаты по уровню доступа пользователя. Тест, который проверяет, выполнялся ли запрос к БД, но не проверяет, как работает фильтрация, проверяет не то, что надо.
Плохой тест требует слишком много подготовки. Для примера выше (бд и фильтрация по уровню доступа) можно представить как в тесте создаются:
1. Тестовая группа пользователя
2. Тестовый пользователь
3. Список прав тестового пользователя
4. Список объектов возвращаемых из базы данных
5. Список прав доступа к объектам возвращаемым их базы данных.

И только после этого начинается непосредственно тестирующий код. Ужас 🙂 Такой тест самого верного сторонника TDD переманит на сторону тестирования верой (верую, что этот код работает). Бороться с этой проблемой можно как рефакторингом тестируемого кода, так и созданием фабрики стандартных тестовых объектов.

Плохой тест содержит слишком сложные выражения в assert* или проверяет нескольких фактов одним вызовом assert*. Хотя матчеры hamcrest и позволяют строить выражения вида assertThat(pinkPanther(), both(pink).and(panther));, злоупотреблять ими не стоит. Гораздо надёжнее придерживаться правила одной проверки на один факт. И уж точно не надо писать

assertThat(getList(), 
    allOf(
     both(
      not(empty()))
     .and(
          hasSize(4)),
    contains("user","data"),
    containsInAnyOrder(
      "everything",
      "is",
      "fine"))

assertThat(getList(),

allOf(

both(

not(empty()))

.and(

hasSize(4)),

contains("user","data"),

containsInAnyOrder(

"everything",

"is",

"fine"))

Плохой тест слишком медленный. Количество модульных тестов обычно начинается с тысяч и если они не будут выполняться очень быстро, их просто перестануть выполнять. Подумайте сами — десять тысяч тестов длительностью в секунду выполняютcя без малого 4 часа. Тоже число тестов длительностью по миллисекунде выполнится всего за 10 секунд.
Плохой тест зависит от своего окружения. Если тесту нужна внешняя конфигурация, особенные настройки операционной системы, определённая версия jdk и т.д., его надо срочно переписать.

Постарайтесь писать поменьше плохих тестов и побольше хороших

Рекомендованное чтение