Является ли Pex (Test Generation) действительно полезным инструментом?

Question

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

Но чаще всего мы создаем тесты на деловое поведение. Давайте рассмотрим пример из классической книги Бека:

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

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

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

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

Answer 1

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

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

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

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

[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);
}

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

[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. Сначала напишите параметризованный модульный тест, Pex найдет неисправную ошибку, исправит ошибку, Pex найдет следующую неисправную ошибку и т. Д ...

Делает ли это Pex полезным инструментом? Ты будешь судьей.

Answer 2

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

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

   Когда вы используете Pex для получения 100% покрытия кода, на самом деле это не помогает вам лучше охватить тестирование само по себе, но то, что делает , - это дать любому куску производственного кода некоторый тест, который может использоваться для отладчика. Фактически, презентация Pex в качестве конференции показывает использование Pex для этой цели. Программист сказал: «Ну и дела, посмотрите на этот метод в NHibernate. Я хотел бы пройтись по нему в отладчике, чтобы увидеть, что он делает, но как мне даже вызвать этот метод через обычную« точку входа в бизнес »в библиотека? Ничего не зная о библиотеке, ты не сможешь. Поэтому он запустил Pex и смог пройтись по коду со всевозможными параметрами. Интересно, да. Полезно, может быть, возможно, нет.

2. В дополнение к автоматически создаваемым тестам Pex также полезен для параметризации ваших тестов. Намного лучше создавать модульные тесты, основанные на данных. Зачем писать один и тот же код снова и снова, с разными параметрами. Запишите его один раз и передайте параметры из источника данных.

3. Pex также полезен в качестве простой структуры заглушки. Вероятно, это самый простой способ создания фиктивных объектов с использованием нового лямбда-выражения, которое гораздо проще понять, чем сложные интегрированные среды, такие как RhinoMocks и т. Д. С помощью Moles вы также можете использовать не только интерфейс, но и конкретные не виртуальные методы в классах.

4. Я бы тоже был осторожен со слоем "тестирование в бизнес-логике", слишком много. Вы можете легко приступить к поведенческой разработке, которая не предназначена для модульного тестирования. Там вы тестируете на предмет спецификаций. Если это все, что вы сделали, как бы вы протестировали, скажем, пользовательские структуры данных и т. Д., Которые не имеют никакой коммерческой ценности, но являются внутренними библиотеками, используемыми во всем приложении.