День 2043. #Testing
Автоматизированные Тесты. Начало
Тесты важны для обеспечения качества приложения. Существует множество видов тестов: модульные, интеграционные, функциональные, дымовые и т.п. Но некоторые тесты не вписываются ни в одну категорию, и создатели придают им другое значение, создавая их.

Тесты — это компромиссы:
- Уверенность: Гарантирует ли тест, что приложение работает так, как ожидалось?
- Продолжительность: Сколько времени требуется для выполнения теста?
- Надёжность: Выдаёт ли тест случайные сбои?
- Усилия по написанию: Легко ли реализовать тестовый сценарий?
- Стоимость обслуживания: Сколько времени нужно на обновление теста при изменении кода?

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

Теперь я принял новую стратегию, которая оказалась очень эффективной для разработанного мной приложения. Мои текущие практики включают:
1. Тестирование в основном публичного API, поскольку внутренние компоненты неявно тестируются и включаются в метрики покрытия кода. Публичный API – не обязательно классы или методы, а может быть точками входа приложения или конечными точками HTTP.
2. Минимизация использования моков, резервирование их для особых случаев, таких как взаимодействие клиентов с внешними сервисами.
3. Использование строгого статического анализа, чтобы избежать написания тестов для того, что может быть обнаружено во время компиляции.
4. Больше утверждений в коде (например, Debug.Assert).

Это даёт несколько преимуществ:
1. Меньше тестов нужно поддерживать.
2. Пользовательские сценарии чётко определены и протестированы.
3. Не нужно переписывать тесты при рефакторинге кода или изменениях в реализации, пока API не изменился.
4. Возможно безопасно рефакторить код, обеспечивая неизменное поведение.
5. Помогает выявлять устаревшие сегменты кода.

Тестирование публичного API
Публичный API — это то, как ваше приложение отображается для пользователей. Публичный API может отличаться в зависимости от типа проекта:
- Библиотека — классы и методы, доступные пользователям библиотеки.
- Веб-API — конечные точки HTTP.
- Приложение CLI — аргументы командной строки.

Зачем тестировать публичный API?
- Вы гарантируете, что приложение работает, как ожидается, и в тестах, и когда его будут использовать пользователи.
- Вы не связаны с деталями реализации, поэтому вы можете рефакторить код, не обновляя тесты, пока поведение не изменится.
- Меньше тестов, чем при тестировании многих отдельных классов или методов.
- Увеличивается покрытие кода, т.к. тестируется больше частей приложения.
- Легче отлаживать приложение, т.к. можно воспроизводить полные сценарии.

Например, если вы пишете приложение ASP.NET Core, не тестируйте класс Controller напрямую. Используйте WebApplicationFactory для настройки и запуска сервера, затем отправляйте запрос и проверяйте ответ. Так вы тестируете приложение в целом, включая маршрутизацию, привязку модели, фильтры, промежуточное ПО, внедрение зависимостей и т. д. Также возможен рефакторинг на Minimal API или изменение промежуточного ПО без обновления тестов.

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

Тестирование общедоступного API не предполагает тестирование методом черного ящика. Можно заменить некоторые зависимости. Например, проверить, как ведёт себя приложение, когда сторонний API возвращает ошибку.

Продолжение следует…

Источник: https://www.meziantou.net/automated-tests.htm
Автор оригинала: Gérald Barré