Рекомендации по созданию модульных тестов

1. Не надо тестировать каждый класс, каждый интерфейс. Только самые значимые. Модульные тесты призваны проверять базовую функциональность и наиболее критичные участки – наиболее “ценный” код. Модульные тесты – это инструмент, который должен себя оправдывать. Необходимо найти разумную границу между отказом от тестов и полным покрытием кода. К примеру, если найден баг, то можно проанализировать, можно ли было его поймать модульными тестами и учесть это в будущем.

2. Модульные тесты полезны для проверки сценариев, которые трудно или дорого воспроизвести при тестировании через пользовательский интерфейс.

3. Особое внимание логике приложения (if, for, while и т.п.).

4. Нужно минимизировать время прогона модульных тестов. Они должны выполняться быстро, иначе в них нет смысла. Поэтому каждый модульный тест должны быть достаточно “скоротечным”.

5. Модульный тест должен быть простым, охватывать 1-2 метода. Если зажегся красный свет, разработчику сразу должно быть ясно, в чем причина возникшей проблемы.

6. В модульных тестах желательно обходиться без обращения к базам данных, сокетам и прочим объектам “внешнего мира”, иначе это будет не модульный, а интеграционный тест. Напомним, что тест должен выполняться быстро, иначе в нем нет никакого смысла. Это значит, что в модульном тесте не должно быть никакого ввода-вывода.

7. Модульные тесты – это основание пирамиды тестирования, проверка базовой функциональность, отлов логических ошибок. В деле обеспечения качества продукта они необходимы, но недостаточны. Над ними располагаются функциональные тесты – к примеру, охватывающие взаимодействие с базами данных или объектами в Интернете. Затем следуют интеграционные тесты, проверяющие взаимодействие компонентов системы. Далее идут приемочные тесты с позиции пользователя (воспроизвести базовые сценарии, по которым будет действовать пользователь системы). И наконец, исследовательское тестирование – вершина пирамиды и полновластная епархия тестировщика.