Есть ли опыт написания модульных тестов

Что проверяют

Пишете ли вы тесты сами как часть задачи и понимаете ли, каким должен быть хороший модульный тест. Следом обычно просят показать, как вы протестируете класс, который зависит от базы или от текущего времени.

Как отвечать

Отвечайте от своего опыта и называйте конкретику: какой проект, какие классы покрывали, что именно ловили тесты. Каркас для .NET:

• фреймворк: xUnit, NUnit или MSTest. В xUnit тест помечается [Fact], параметризованный [Theory] с [InlineData], запуск через dotnet test;
• структура: Arrange, Act, Assert, одна проверяемая идея на тест, имя вроде CreateOrder_WhenCartIsEmpty_Throws;
• зависимости: код получает их через конструктор как интерфейсы, в тестах они подменяются через Moq или NSubstitute. Время берётся из TimeProvider (появился в .NET 8), а не из DateTime.Now, иначе тест зависит от часов;
• проверки: встроенные Assert или Shouldly. У FluentAssertions с восьмой версии коммерческая лицензия, это стоит знать, если предлагаете его в проект;
• граница с интеграционными: репозиторий на EF Core честнее проверять на настоящей базе через Testcontainers, а API через WebApplicationFactory. Провайдер InMemory Microsoft для тестов не рекомендует: он не ведёт себя как реляционная база;
• CI: тесты гоняются на каждый пул-реквест, покрытие собирает coverlet.

Результат описывайте своими фактами: сколько регрессий тесты поймали до релиза, сколько идёт прогон. Выдуманные «на 30% меньше багов» интервьюер слышит сразу.

Если опыт небольшой, скажите честно: например, в текущей команде тестов нет, но в своём проекте вы покрыли сервисный слой на xUnit и Moq. И покажите, как бы вы выстроили тестирование на новом месте.

Где спотыкаются

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

Мокают всё подряд и проверяют через Verify каждый вызов. Такие тесты ломаются при любом рефакторинге и не ловят реальные ошибки.

Ставят целью процент покрытия. Высокое покрытие геттеров не защищает от ошибок в расчётах, важнее покрыть ветвления бизнес-логики.