День 2811. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

49. Модульное тестирование
«Как бы вы использовали модульные тесты в приложении .NET? Опишите процесс настройки фреймворка тестирования, написания базового теста и его запуска. Укажите также, каких лучших практик вы придерживаетесь при написании модульных тестов».

Хороший ответ
Начнём с добавления проекта тестов в решение. Например, для тестового фреймворка xUnit это можно сделать с помощью .NET CLI:
dotnet new xunit -n YourProjectName.Tests
Нужно убедиться, что тестовый проект содержит ссылку на тестируемый проект.
При структурировании тестов полезен шаблон AAA (Arrange, Act, Assert). Он предполагает подготовку окружения (Arrange), выполнение тестируемой функциональности (Act) и проверку результата (Assert). Если мы тестируем метод, складывающий два числа, тест может выглядеть так:

using Xunit;
public class CalculatorTests
{
  [Fact]
  public void Add_ReturnsCorrectSum()
  {
    // Arrange
    var calc = new Calculator();
    int a = 5;
    int b = 7;

    // Act
    var result = calc.Add(a, b);
    
    // Assert
    Assert.Equal(12, result);
  }
}

Запустить тесты можно с помощью .NET CLI:
dotnet test YourProjectName.Tests
либо в IDE через «Обозреватель тестов» (Test Explorer).

Основные принципы написания тестов
- Изоляция: обеспечение независимости каждого теста; он не должен зависеть от других тестов.
- Соглашения об именовании: использование понятных имён для тестовых методов, описывающих ожидаемое поведение теста.
- Моки: использование фреймворков для создания заглушек (например, Moq), чтобы изолировать тесты от внешних зависимостей и обеспечить их детерминированность.
- Покрытие тестами: стремление к высокому уровню покрытия, но с упором на проверку критически важных путей и логики, а не простых методов доступа (геттеров/сеттеров).

Распространённый неудачный ответ
«Чаще всего я просто копирую существующие тесты из другого проекта. Обычно они похожи, а xUnit не требует какой-то особой конфигурации».

Почему этот подход неверен:
- Непонимание конкретных требований: у каждого проекта могут быть уникальные требования и конфигурации, которые такой подход не учитывает. Копирование без понимания контекста может привести к созданию бесполезных тестов или пропуску граничных случаев.

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

- Игнорирование специфики тестов: тесты должны разрабатываться с учётом конкретной логики и сценариев данного проекта, а не на основе универсальных случаев, которые могут быть неприменимы.

Подобный неверный ответ часто свидетельствует о непонимании принципов тестирования или пренебрежении процессами обеспечения качества, указывая на поверхностный подход к тестированию ПО.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md