.NET Разработчик
День 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
11 · 897 ·