Что хотят услышать интервьюеры:

Важно показать, что проверки для кода — это не «дополнительная работа», а часть процесса разработки. Хороший ответ демонстрирует, что тесты писались осознанно: для критичных сценариев, регрессий и сложной логики. Также ценится понимание разницы между ручными сценариями и автоматическими проверками.

Определение:

Тестовые сценарии — это заранее описанные шаги и ожидаемые результаты для проверки поведения системы. Автоматические проверки — это тесты, которые запускаются программой и подтверждают, что код работает как ожидается. В C# это часто unit-тесты, интеграционные тесты или простые проверки бизнес-логики.

Пример использования:

Например, при разработке сервиса расчёта скидки для заказов можно было написать unit-тесты на разные условия: обычный заказ, заказ с промокодом и заказ с превышением порога скидки. Это помогает быстро проверить, что изменения в логике не ломают уже работающие сценарии.

using Xunit;

public class DiscountServiceTests
{
    [Fact]
    public void ApplyDiscount_WhenOrderAmountIsHigh_ReturnsDiscountedPrice()
    {
        var service = new DiscountService();

        var result = service.ApplyDiscount(1000);

        Assert.Equal(900, result);
    }

    [Fact]
    public void ApplyDiscount_WhenOrderAmountIsLow_ReturnsOriginalPrice()
    {
        var service = new DiscountService();

        var result = service.ApplyDiscount(100);

        Assert.Equal(100, result);
    }
}

public class DiscountService
{
    public decimal ApplyDiscount(decimal amount)
    {
        if (amount >= 1000)
            return amount * 0.9m;

        return amount;
    }
}

Пояснение кода:

В примере есть простой класс DiscountService, который применяет скидку 10% только для заказов от 1000 и выше.
Первый тест проверяет, что при сумме 1000 результат становится 900.
Второй тест проверяет, что при сумме 100 скидка не применяется и значение остаётся без изменений.
Такой подход позволяет быстро ловить ошибки при изменении бизнес-логики.

Ключевые моменты:

Хорошо упомянуть, что тесты писались для критичной бизнес-логики или для защиты от регрессий.
Полезно разделять ручные тестовые сценарии и автоматические тесты.
Для C# уместно назвать unit-тесты, а при необходимости — интеграционные тесты.
Важно показать, что тесты делались на понятные входы и ожидаемые результаты.
Сильный ответ — это не только факт написания тестов, но и эффект: быстрее проверка, меньше ошибок, безопаснее рефакторинг.

Бывали ли ситуации, когда вы создавали тестовые сценарии или автоматические проверки для своего кода?