Какими принципами руководствуешься при выборе классов для покрытия тестами
Что проверяют
Умеете ли вы тратить время на тесты там, где они окупаются, а не гнаться за процентом покрытия. Следом часто спрашивают, какое покрытие вы считаете нормальным и что делать с классом, который не протестировать без базы.
Как отвечать
Опирайтесь на соотношение риска и стоимости теста:
- доменная логика: расчёты, правила, валидация, машины состояний. Это код с понятным входом и выходом, тесты на него дешёвые и ловят самые дорогие ошибки: скидки, тарифы, платежи;
- сложность: методы с большой цикломатической сложностью и граничными условиями. Такие места подсвечивают метрики кода в Visual Studio и Rider, покрытие меряют через
coverletс отчётом в ReportGenerator; - частота изменений: класс, который правят каждый спринт, без тестов регрессирует. Пересечение сложности и частоты коммитов даёт хороший список приоритетов;
- баги: на каждый найденный дефект сначала падающий тест, потом исправление;
- публичный контракт: библиотечный код и API, на которые завязаны другие команды.
Что обычно не покрывают юнит-тестами: DTO без поведения, автосвойства, маппинг один в один, регистрацию в DI, тонкие контроллеры. Репозитории на EF Core честнее проверять интеграционными тестами на настоящей базе через Testcontainers, чем мокать DbContext: провайдер InMemory ведёт себя не как реальная СУБД.
Назовите инструменты: xUnit или NUnit, Moq или NSubstitute для зависимостей. Класс, который трудно тестировать из-за DateTime.Now или статических вызовов, это сигнал к рефакторингу: зависимость выносят в интерфейс, а для времени с .NET 8 есть TimeProvider.
Где спотыкаются
Называют целью 100% покрытия. Метрика легко набирается тестами без проверок и ничего не говорит о качестве, разумнее говорить о покрытии критичной логики.
Мокают всё подряд, включая то, что тестируют. Такие тесты повторяют реализацию и ломаются при любом рефакторинге.
Отвечают про SOLID, KISS и DRY как про «принципы выбора классов». Это принципы проектирования: они делают код тестируемым, но не отвечают на вопрос, что тестировать первым.