Действительно ли полезный инструмент Pex (Test generation)?

Да, можно генерировать тесты по граничным значениям для таких функций, как "Сумма" или "Разделить". Pex - хороший инструмент здесь.

Но чаще мы создаем тесты по бизнес-поведению. Рассмотрим пример из классической книги Beck tdd:

[Test]
public void ShouldRoundOnCreation()
{
  Money money = new Money(20.678);
  Assert.AreEqual(20.68,money.Amount);
  Assert.AreEqual(2068,money.Cents);
}

Может ли этот тест быть сгенерирован? Нет:) 95% тестов в моих проектах проверяют бизнес-логику и не могут быть сгенерированы.

Pex (особенно в паре с Moles) может дать 100% покрытие кода, но высокий коэффициент покрытия кода тестового набора никогда не указывает, что код хорошо протестирован - он дает ложную уверенность в том, что все протестировано. И это очень опасно.

Итак, вопрос в том, действительно ли полезен Pex-инструмент Pex?

Ответ 1

Я думаю, вы ошибаетесь в том, как использовать Pex: мы настоятельно рекомендуем пользователям писать утверждения в их параметризованных модульных тестах.

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

Если вы используете Pex для получения набора тестов с высоким охватом кода без написания утверждений, вы получаете только то, что вы просили: покрытие кода и гарантированные исключения во время выполнения. Pex "только" пытается покрыть ветки (1 утверждение = 1 ветвь), если нет ветвей для покрытия (нет утверждений), это не приведет к появлению тестовых примеров.

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

[PexMethod]
public void RoundInBounds(double value) 
{
    var money = new Money(value);
    // distance between value and amount should be at most 0.01/2
    Assert.AreEqual(value, money.Amount, 0.005);
}

Существует также ряд шаблонов, которые можно использовать для их записи. Например, ваш класс "Деньги", вероятно, идемпотент: если вы подаете значение "Сумма" обратно в экземпляре "День", вы получаете Сумму обратно. Это элегантно преобразуется в параметризованный unit test:

[PexMethod]
public void RoundIsIdempotent(double value) 
{
     var first = new Money(value).Amount;
     var second = new Money(first).Amount;
     Assert.AreEqual(first, second, 0.0001);
}

Обратите также внимание, что параметризованные модульные тесты определенно принадлежат к миру TDD. Просто напишите параметризованный unit test во-первых, Pex найдет ошибку, исправьте ошибку, Pex найдет следующую ошибку и т.д.

Это делает Pex полезным инструментом? Вы будете судьей.

Ответ 2

В Pex есть несколько полезных вещей.

Покрытие кода. Положите Pex в сторону на секунду. В целом, 100% -ый охват кода не обязательно означает, что у вас хороший охват кода. Это просто означает, что любой путь выполняется, но программа имеет поток данных, и тестирование этого кода разными, дополнительными входами дает вам лучшее "покрытие теста", если не покрытие кода. Вот, я просто повторяю вашу мысль. 100% -ый охват кода не всегда хорош, но вы можете с уверенностью сказать, что 25% -ый охват кода плох, так как использование кода полезно. Когда у вас низкий охват кода, вы точно знаете, что у вас низкий охват тестирования.

Когда вы используете Pex для покрытия 100% кода, это не поможет вам получить лучшее тестовое покрытие как таковое, но то, что он делает, это дать какой-либо фрагмент производственного кода какой-то тест, который можно использовать для отладчика. Фактически, презентация Pex в качестве конференции показывает использование Pex для этой самой цели. Программист сказал: "Дай, посмотри на этот метод в NHibernate. Я хотел бы пройти через него в отладчике, чтобы посмотреть, что он делает, но как я даже вызываю этот метод через обычную" точку входа в бизнес "в библиотека? Не зная ничего о библиотеке, вы не можете, поэтому он запустил Pex и смог выполнить код со всеми параметрами. Интересно, да. Полезно, может быть, возможно, возможно, нет.
/li >
В дополнение к автоматически созданным тестам Pex также полезен для параметризации ваших тестов. Гораздо лучше создавать модульные тесты, которые управляются данными. Зачем писать один и тот же код снова и снова, с разными параметрами. Напишите его один раз и подайте параметры из источника данных.
Pex также полезен как простая структурная структура. Это, вероятно, самый простой способ создания макетных объектов с использованием нового лямбда-выражения, который намного легче понять, чем сложные структуры, такие как RhinoMocks и т.д. С помощью Moles вы также можете заглушить не только интерфейс, но и конкретные не виртуальные методы в классах.
Я также был бы слишком осторожен с словом "тестирование на бизнес-логике". Вы можете легко перейти к разработке Behavioral Driven Development, которая не предназначена для модульного тестирования. Там вы тестируете спецификацию. Если это все, что вы сделали, как бы вы протестировали, скажем, пользовательские структуры данных и т.д., Которые не имеют бизнес-ценности, а являются внутренними библиотеками, используемыми во всем приложении.