Как вы разрабатываете и тестируете задачи

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

Есть ли у вас рабочий цикл от задачи до мержа и где в нём место тестам. Список слов вроде Agile, SOLID и TDD интервьюеру не нужен, ему интересно, что вы делаете руками. Следом обычно спрашивают, как вы тестируете код, который ходит в базу, и пишете ли тесты до кода.

Как отвечать

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

• до кода: уточнить критерии приёмки и граничные случаи, большую задачу разделить на части, которые можно выкатить отдельно;
• разработка: ветка от main, небольшие коммиты, логика отделена от инфраструктуры через интерфейсы и DI из Microsoft.Extensions.DependencyInjection, чтобы её можно было тестировать;
• модульные тесты: xUnit или NUnit, заглушки через Moq или NSubstitute. Проверяется поведение и граничные случаи, а не приватные методы;
• интеграционные тесты: для ASP.NET Core WebApplicationFactory<Program> поднимает приложение в памяти, а база настоящая, в контейнере через Testcontainers. Провайдер EF Core InMemory для этого не годится: он не проверяет SQL, транзакции и ограничения, и сама Microsoft не рекомендует его для тестов;
• локально и в CI: dotnet test с покрытием через coverlet, тот же набор в пайплайне (GitHub Actions, GitLab CI или Azure DevOps) блокирует мерж при падении;
• ревью и проверка после выкладки: PR с описанием, как проверяли, после деплоя взгляд на логи и метрики.

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

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

Перечисляют методологии и принципы вместо процесса. На уточнение «покажите на последней задаче» ответа нет.

Говорят «тестирует QA». Разработчику на C# в любом случае нужны свои модульные и интеграционные тесты.

Считают тест на EF Core InMemory интеграционным. Он зелёный там, где реальный SQL Server или PostgreSQL упадёт на ограничении или на переводе LINQ в SQL.