FAQ по модульному тестированию

Q: Делать ли несколько тестов для разных вариантов поведения одной функции или обязательно писать один тест на одну функцию?

A: Большинство авторов рекомендует придерживаться правила «один assert на один тест», хотя в некоторых случаях это довольно спорно. Посмотрите в рекомендации по стилю вашей компании, спросите у старших товарищей или соседа по столу. Если ответа нет — поступайте как вам удобно. Я предпочитаю для коротких функций писать один тест, проверяющий все варианты, а для сложных функций выделять каждый вариант поведения в отдельный тест.

Q: Писать ли тесты для геттеров/сеттеров?

A: Корректный ответ на этот вопрос «Если цикломатическая сложность
функции равна 1, юнит тест для неё писать не нужно». Правильный ответ — это зависит. Если старшие коллеги, руководству по кодингу, итд. требуют 100%
покрытия кода тестами, то нужно. Если не требуют, то не нужно, если вы доверяете компилятору. 🙂 Или переходите на project lombok и вопрос отпадёт сам собой 🙂 Конечно, если ваше геттеры/сеттеры не просто возвращают/устанавливают значения, а проводят какие-либо действия над ними (хотя бы проверку), то покрывать их юнит-тестами нужно обязательно.

Q: Стремиться ли к 100% покрытию кода юнит-тестами?

A: 100% это прекрасная цифра, к которой, несомненно, нужно стремиться, но без фанатизма. Следует понимать, что заметную часть кода будут составлять функции с цикломатической сложностью в 1, функции которые присутствуют для только для соответствия интерфейсу или запрета каких либо действий, кода, который генерируется во время компиляции или даже исполнения. И весь этот код покрывать тестами либо крайне сложно, либо бессмысленно, либо и то и другое одновременно. И не забывайте, что 20% усилий дают 80% результата.

Q: Как проверять private функции?

A: Никак:) Private функции это сугубо внутреннее дело вашего класса, внешнему миру нет до них никакого интереса.  Внешний мир (а значит и юнит тесты) интересуются только внешним поведением класса, а значит и тестировать надо только его. И, изменяя условия тестов, «дотягиваться» до не публичных функций. Если же у вас не получается написать такой набор тестов, чтобы обращаясь только через публичные методы проверить и не публичный код, подумайте, а что вообще делает этот непроверяемый код и зачем он нужен

Q: Я хочу сохранить состояние тестируемого объекта между тестами в JUnit, но это не всегда работает, почему?

A: Потому, что JUnit вызывает тесты в каком-то случайном порядке и не гарантирует что этот порядок всегда будет одинаковым, поэтому тесты
не должны зависеть друг от друга. Однако с версии 4.11 появилась возможность попросить JUnit вызывать тесты в алфавитном порядке. Для того добавьте к классу с тестами аннотацию @FixMethodOrder :

Стоит отметить, что значения MethodSorters.JVM  и MethodSorters.DEFAULT  активируют исполнению по умолчанию, в случайном порядке.