.NET 4,0 контракта кода - Как они будут влиять на поблочное тестирование?
static byte[] SliceMe(byte[] source, int length)
{
byte[] destfoo = new byte[length];
Array.Copy(source, 0, destfoo, 0, length);
return destfoo;
}
//
var myslice = SliceMe(sourcearray,41);
4 ответа
Я не думаю, что модульное тестирование и контракты так сильно мешают друг другу, и если что-то контракты должны помочь модульному тестированию, так как они устраняют необходимость добавлять утомительные повторяющиеся тесты на недопустимые аргументы. Контракты определяют минимум, которого вы можете ожидать от функции, тогда как модульные тесты пытаются проверить фактическое поведение для определенного набора входных данных. Рассмотрим этот надуманный пример:
public class Order
{
public IEnumerable Items { get; }
}
public class OrderCalculator
{
public double CalculateTotal(Order order)
{
Contract.Requires(order != null);
Contract.Ensures(Contract.Result<double>() >= 0);
return 2.0;
}
}
Очевидно, что код удовлетворяет условиям контракта, но вам все равно потребуется модульное тестирование, чтобы убедиться, что он действительно ведет себя так, как вы ожидаете.
В чем преимущество?
Допустим, вы хотите убедиться, что метод никогда не возвращает null . Теперь, с модульными тестами, вам нужно написать несколько тестовых примеров, в которых вы вызываете метод с различными входами и проверяете, что результат не равен нулю. Проблема в том, что вы не можете протестировать все возможные входные данные.
С контрактами кода вы просто заявляете, что метод никогда не возвращает null . Статический анализатор будет жаловаться, если это невозможно доказать. Если он не жалуется, значит, вы знаете, что ваше утверждение верно для всех возможных входных данных.
Меньше работы, гарантия идеальной правильности. Что не нравится?
Контракты позволяют вам сказать, какова фактическая цель кода, в отличие от того, чтобы разрешать все, что делает код, с любыми случайными аргументами, передаваемыми ему как определение с точки зрения компилятора , или следующий читатель кода. Это позволяет значительно улучшить статический анализ и оптимизацию кода.
Например, если я объявляю целочисленный параметр (с использованием обозначения контракта) в диапазоне от 1 до 10, и у меня есть локальный массив в моей функции, объявленный таким же размер, который индексируется параметром, компилятор может сказать, что нет возможности ошибки индекса, таким образом создавая лучший код.
Вы можете указать, что null является допустимым значением в контракте.
Цель модульного тестирования заключается в том, чтобы проверить динамически , что код достигает той заявленной цели, которую он имеет. Тот факт, что вы написали контракт для функции, не означает, что код это делает или что статический анализ может проверить, что код делает это. Модульное тестирование никуда не денется.
Ну, это не помешает модульному тестированию в целом. Но, как я видел, вы упомянули кое-что о TDD.
Если я подумаю об этом с этой точки зрения, я думаю, это может / может изменить процедуру по сравнению со стандартной
- создать метод (просто подпись)
- создать модульный тест - > реализовать тест
- запустить тест: дать ему потерпеть неудачу
- реализовать метод, взломать его до конца, чтобы он заработал
- запустить тест: увидеть, пройти
- рефакторинг вашего (возможно беспорядочного) method body
- (повторно запустите тест, чтобы убедиться, что вы ничего не сломали)
Это была бы действительно сложная полнофункциональная процедура модульного тестирования. В таком контексте, я думаю, вы могли бы вставить контракты кода между 1-й и 2-й точками, например
- создать метод (просто подпись)
- вставить контракты кода для входных параметров методов
- создать Unit test -> реализовать тест
- ...
Преимущество, которое я вижу на данный момент, заключается в том, что вы можете писать более простые модульные тесты в том смысле, что вам не нужно будет проверять все возможные пути, поскольку некоторые из них уже учтены вашим определенные контракты. Это просто дает вам дополнительную проверку, но не заменяет модульное тестирование, поскольку в коде всегда будет больше логики, больше путей, которые нужно будет тестировать с помощью модульных тестов, как обычно.
Изменить
Другой вариант, который я не использовал Раньше не рассматривал добавление контрактов кода в части рефакторинга. В основном как дополнительный способ уверенности. Но это как-то было бы излишним, и поскольку люди не любят делать лишнее ...
Мне нужно проверять все возможные пути, поскольку некоторые из них уже учтены в определенных вами контрактах. Он просто дает вам дополнительную проверку, но не заменяет модульное тестирование, поскольку в коде всегда будет больше логики, больше путей, которые нужно будет тестировать с помощью модульных тестов, как обычно.Изменить
Другой вариант, который я не использовал Раньше не рассматривал добавление контрактов кода в части рефакторинга. В основном как дополнительный способ уверенности. Но это как-то было бы излишним, и поскольку люди не любят делать лишнее ...
Мне нужно проверять все возможные пути, поскольку некоторые из них уже учтены в определенных вами контрактах. Это просто дает вам дополнительную проверку, но не заменяет модульное тестирование, поскольку в коде всегда будет больше логики, больше путей, которые нужно будет тестировать с помощью модульных тестов, как обычно.Изменить
Другой вариант, который я не использовал Раньше не рассматривал добавление контрактов кода в части рефакторинга. В основном как дополнительный способ уверенности. Но это как-то было бы излишним, и поскольку люди не любят делать лишнее ...
Edit
Другая возможность, которую я раньше не рассматривал, - это добавление контрактов кода в части рефакторинга. В основном как дополнительный способ уверенности. Но это как-то было бы излишним, и поскольку люди не любят делать лишнее ...
Edit
Другая возможность, которую я раньше не рассматривал, - это добавление контрактов кода в части рефакторинга. В основном как дополнительный способ уверенности. Но это как-то было бы излишним, и поскольку люди не любят делать лишнее ...