Что должно и не должно быть охвачено модульными испытаниями?

Очевидно, Я не понимаю модульное тестирование. Это прекрасно, учитывая, что я никогда раньше этого не делал. Я начинаю новый проект и хочу с самого начала испечь модульное тестирование, поэтому я хочу учиться.

Я всегда приравнивал модульное тестирование с охватом кода, полагая, что у вас должны быть модульные тесты, которые охватывают каждую функцию/метод в вашем приложении, но это явно не так, и я полностью не понял эту концепцию.

Итак,

Какие функции выигрывают от модульного тестирования?
Какие функции не должны тестироваться на модуле?

Ответ 1

У меня нет полного ответа (я бы хотел услышать любого, кто это делает, честно), но может хотя бы выслать несколько моментов...

Вы уже на правильном пути, запустив разработку из тестов в первую очередь. Тесты на установку модульной установки в существующие приложения сложны и редко обеспечивают реальную выгоду (вместо этого они часто дают ложное представление о покрытии кода). Правильный TDD всегда является предусмотрительным, никогда не запоздалым.
Я бы не стал тестировать частные функции. Различные инструменты покрытия кода могут сказать, что он оставлен непроверенным, но если он закрыт, то его функциональность должна быть проверена путем тестирования общедоступных методов. Частные методы являются внутренними, а не частью API, ничто за пределами класса (даже тесты) не должно знать или заботиться о них, так как они могут легко измениться, если будет изменена реализация этого класса.
Сосредоточьтесь на открытом API вашего кода. Напишите тесты против ваших интерфейсов, а не против ваших классов. Сами классы впоследствии реализованы и протестированы против тестов.
Наконец, и очень важно изучить, что вы делаете и каковы его преимущества. Тестирование блок-единиц не является коричневым и обслуживающим процессом. Один из них не достигает хорошего тестового покрытия, просто называя тесты, но понимая TDD и как его реализовать. Это займет практику. Одно из предложений, которое я хотел бы дать, - это сделать правильный проект TDD, а также попытаться выполнить ретро-тестирование в существующий проект. Мы можем сказать друг другу весь день, что первое лучше, чем последнее, но, делая оба, вы можете действительно различать различия и лучше понимать, почему это лучше. Это приведет вас не только к написанию тестов, но и к тому, чтобы быть более опытным специалистом TDD и тем, что он действительно приносит в таблицу. Любой может писать тесты, но слишком часто они просто теряют время, если они действительно не понимают, что происходит.

Ответ 2

В соответствии с методологией TDD (Test Driven Development) следует протестировать каждую общедоступную функцию и каждый путь выполнения в этой функции.

Ответ 3

Единичное тестирование - это инструмент, и есть много подходов к тому, как его использовать. Вот мой подход:

Я пишу свои модульные тесты против подписей Service и DAO и не столько против DTO, либо типов сущностей. Большинство типов значений будут косвенно проверены. методы equals и hashCode в DTO и типы сущностей должны быть протестированы.

Я использую оба чистых модульных теста с издеваемыми зависимостями и интеграционными тестами с полным бэкэндом. Для правильного покрытия вам нужны оба.