Я смотрел веб-трансляции Rob Connerys в приложении MVCStoreFront, и я заметил, что он был модульным тестированием даже самых мирских вещей, таких как:
public Decimal DiscountPrice
{
get
{
return this.Price - this.Discount;
}
}
Будет тест вроде:
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,80);
}
В то время как я все для модульного тестирования, мне иногда интересно, действительно ли эта форма тестирования первой разработки действительно выгодна, например, в реальном процессе, у вас на 3-4 слоя выше вашего кода (бизнес-запрос, документ требований, Архитектурный документ), где фактическое определенное бизнес-правило (цена скидки - цена-скидка) может быть ошибочным.
Если в этом случае ваш unit test ничего не значит для вас.
Кроме того, ваш unit test является еще одной ошибкой:
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,90);
}
Теперь тест испорчен. Очевидно, что в простом тесте это не имеет большого значения, но, говорят, мы тестировали сложное бизнес-правило. Что мы получаем здесь?
Ускорьте два года на срок службы приложений, когда разработчики обслуживания поддерживают его. Теперь бизнес меняет свое правило, и тест снова ломается, некоторые разработчики новичков затем неправильно исправляют этот тест... у нас теперь есть еще одна ошибка.
Все, что я вижу, является более вероятными точками отказа, без реального положительного результата, если цена скидки неверна, тестовая команда все равно найдет проблему, как модульное тестирование сохранит любую работу?
Что мне здесь не хватает? Пожалуйста, научите меня любить TDD, поскольку я с трудом принимаю его как полезный до сих пор. Я тоже хочу, потому что хочу оставаться прогрессивным, но для меня это просто не имеет смысла.
РЕДАКТИРОВАТЬ: пара людей продолжает упоминать, что тестирование помогает обеспечить соответствие спецификации. По моему опыту, спецификация также ошибалась, чаще всего, но, возможно, я обречена работать в организации, где спецификации написаны людьми, которые не должны писать спецификации.
