Я продолжаю сомневаться в доверии и в том, как важно доверять нашим тестам. Если тест является детерминированным, он повышает уровень нашего доверия. Если это не так, мы можем поставить под сомнение его результат, за которым последуют и другие тесты.
Давайте начнем с простого примера. Что не так с этой картиной?
|
1
2
3
4
5
6
7
8
|
public class CreditCard{ DateTime expirationDate = new DateTime(2017,12,15); public bool IsExpired() { return (DateTime.Now > expirationDate); }} |
Это проверенный код. Итак, мы можем написать этот тест:
|
1
2
3
4
5
|
[TestMethod]public void IsExpired_Today_False(){ var card = new CreditCard(); Assert.IsFalse(card.IsExpired());} |
Который проходит. Пока не наступит конкретный день, а затем он потерпит неудачу. Или этот код:
|
1
2
3
4
5
6
7
8
|
public class Settings{ public string GetFirstValue() { var lines = File.ReadLines("config.sys"); return lines.First(); }} |
И его тест:
|
1
2
3
4
5
6
7
|
[TestMethod]public void FirstLine_OfConfigSys_ContainsDevice(){ var settings = new Settings(); var result = settings.GetFirstValue().Contains("Device"); Assert.IsTrue(result); } |
Это происходит, если он находит файл там, где его ожидает, или кто-то редактирует его «в неправильном направлении». Это может выглядеть как зависимости, которым мы не можем доверять постоянно. Это глубже, чем это.
Никогда не принимай
Когда мы пишем код, у нас много предположений. «Счастливый путь» мы обычно кодируем первым, когда предполагаем, что ничего не пойдет не так. Другие пути — это пути, где что-то может пойти не так. К сожалению, мы можем тестировать и кодировать только то, о чем думаем. На самом деле, письмо помогает нам думать о других случаях. Недостатком является то, что если мы используем библиотеку, которую мы не писали, мы думаем меньше о побочных эффектах.
Чтобы убедиться, что мы удаляем неопределенность из наших тестов, нам нужно удалить зависимость от:
- Географическое положение
- Время
- Аппаратная скорость, процессор, память
- Файлы и данные, как существующие, так и отсутствующие
Очевидное решение — смоделировать зависимости или настроить систему на независимость. Посмеиваясь над датой, мы можем проверить случаи «до» и «после» или «посадить» файл и смоделировать его чтение.
Однако, у насмешек есть свои недостатки , поэтому вы должны рассмотреть компромисс.
И иногда, издеваться не вариант. У нас был тест производительности, который должен был работать с определенным ограничением. Это начало терпеть неудачу и проходить и выключаться. Вместо того, чтобы проверить проблему, мы сказали: «О, оставь это, этот тест просто такой». И мы упустили возможности для решения реальных проблем.
Чтобы справиться с основной причиной — предположениями, мы вернемся к нашим друзьям. Просмотрите тесты и код и попробуйте подтвердить предположения или сделать их недействительными (в этом случае удалите код и проверьте). Непроверенные предположения могут вызвать не только ошибки. Код, который вы добавили, усложнит добавление нового кода в будущем. Используйте код, который не только работает, но и действителен.
В следующий раз: Изоляция.
| Ссылка: | Атрибут теста № 9 — Детерминированный от нашего партнера JCG Джила Зильберфельда в блоге Geek Out of Water . |