Недетерминизм в модульном тестировании

Question

Похоже, что во многих модульных тестах значения, которые параметризуют тест, либо запекаются самим тестом, либо объявляются заранее определенным образом.

Например, вот тест взят из модульных тестов NUnit в (EqualsFixture.cs):

[Test] 
public void Int() 
{ 
    int val = 1; 
    int expected = val; 
    int actual = val; 

    Assert.IsTrue(expected == actual); 
    Assert.AreEqual(expected, actual); 
} 

Это имеет преимущество быть детерминированным; если вы один раз запустите тест, и он терпит неудачу, он будет продолжать сбой, пока код не будет исправлен. Тем не менее, вы заканчиваете тестирование только ограниченного набора значений.

Я не могу не чувствовать, что это пустая трата; точно такой же тест, вероятно, будет выполняться с теми же параметрами сотни, если не тысячи раз в течение всего жизненного цикла проекта.

Как насчет того, чтобы рандомизировать как можно больше входных данных во все модульные тесты, чтобы каждый запуск показывал что-то новое?

В предыдущем примере, может быть:

[Test] 
public void Int() 
{ 
    Random rnd = new Random(); 
    int val = rnd.Next(); 
    int expected = val; 
    int actual = val; 
    Console.WriteLine("val is {0}", val); 
    Assert.IsTrue(expected == actual); 
    Assert.AreEqual(expected, actual); 
} 

(Если код ожидается строка, возможно, случайная строка, как известно, действует для конкретной функции можно было бы использовать каждый раз)

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

Полезно? Зло? Есть ли недостатки в этом? Неужели я полностью потерял точку модульного тестирования?

Спасибо за ваши мысли.

Answer 1

Вы хотите, чтобы ваши модульные тесты повторялись, чтобы они всегда вели себя одинаково, если код не изменится. Затем, если код изменится и приведет к сбою в модульном тесте, вы можете исправить код, и модульный тест выполнил свою задачу. Кроме того, вы знаете, что код [вероятно] исправлен, когда модульный тест проходит снова.

После случайных модульных испытаний могут возникать необычные ошибки, но это не обязательно. Если вы знаете, как работает код (сравните белый квадрат и черный ящик с подходом к тестированию), использование случайных значений никогда не должно показывать ничего, что хорошо подумали бы о неслучайных модульных тестах. И мне не хотелось бы, чтобы мне сказали «несколько раз запустить тесты, и эта ошибка должна появиться».

Answer 2

Тестирование должно охватывать ваши варианты использования, не более.

Посмотрите на PEX.

Answer 3

Большая проблема, с которой я сталкиваюсь, заключается в том, что, поскольку это случайное явление, это может не вызвать сбой, пока тест не будет запущен 200, 2000, 3000 или более раз. Если это терпит неудачу в течение 6007 месяцев или лет после того, как дело было написано, это по сути означает, что у вас была ошибка в течение месяцев или лет и она никогда не знала.

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

Answer 4

Испытываете ли вы случайный или оператор равенства?

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

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

Answer 5

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

Что действительно важно, так это то, что каждый тест должен всегда осуществлять один и тот же кодовый путь. Это не совсем то же самое.

Вы можете принять то, что я называю Constrained Non-Determinism в модульном тестировании. Это может привести вас к более Specification-Oriented способам написания тестов.

Answer 6

Если ваше приложение не является детерминированным, вы тратите свое время на тестирование, если оно не является очень маленьким приложением.