Это третий пост о тестовых атрибутах, которые были описаны в более известной статье « Как тестировать ваши тесты ».
Есть история, которую я хотел бы рассказать о своем первом опыте TDD. Вы должны услышать это сейчас (некоторые из вас в n-й раз).
Это было много месяцев назад, когда я только что закончил читать превосходную « Разработка через тестирование на примере » Кента Бека . И я подумал: это положит конец всем моим страданиям.
В то время я работал над коммуникационным компонентом и подумал, почему бы не использовать этот новый TDD?
Я уже совершил один фол перед тем, как написать одну строку тестового кода, потому что я знал что я собирался использовать MSMQ для компонента. Поэтому я выбрал дизайн вместо того, чтобы позволить тестам управлять им. Мой уровень понимания TDD в то время не имеет отношения к этой истории. MSMQ однако есть.
Для тех, кто не знает, MSMQ — это служба Microsoft Queuing, которая работает на всех типах компьютеров под управлением Windows. Инфраструктура для асинхронного обмена сообщениями, которая идеально подходит для работы. Это, однако, немного медленно.
Итак, для моего первого теста я написал тест, который пишет в очередь и ждет, чтобы получить его от нее. Что-то вроде этого:
[TestMethod]
public void ReceiveSentMessage()
{
MyQueue myqueue = new MyQueue();
myqueue.SendMessage(new Message("Hi"));
Message receivedMessage = myqueue.Receive();
Assert.AreEqual("Hi", receivedMessage.Body);
}
Поскольку мы говорим о скорости, вот в чем дело: этот одиночный тест длился около 3 секунд. Что произойдет, если у меня будет еще сто таких?
Смертельная спираль медленных испытаний
Я был так счастлив, что прошел тест, и я не заметил, что это заняло несколько секунд. Большинство людей, начинающих с модульного тестирования, этого не замечают
. Они продолжают накапливать медленные тесты в своем наборе, пока однажды они не достигнут переломного момента.
Давайте возьмем, к примеру, набор, выполнение которого занимает 15 минут. И скажем, я очень терпеливый человек. Я знаю, просто работай со мной.
До этого момента у меня не было проблем с запуском полного комплекта каждый час.
Затем, в этот 15-минутный момент, я решаю, что запуск комплекта каждый час подрывает мою производительность. Поэтому я решил, что буду проводить тесты два раза в день. Одна пробежка закончится обедом, а вторая начнется, когда я выйду из офиса. Таким образом, мне не нужно будет ждать своего времени, результаты будут там, когда я вернусь к работе.
Это оставляет мне больше времени для написания кода (и, надеюсь, несколько тестов). Поэтому я пишу больше кода, и когда я возвращаюсь с обеда, у меня есть несколько красных тестов. Поскольку я не знаю точно, что не так (я не могу точно сказать, какие именно части больших кусков кода, которые я продуктивно добавил, виноваты), я потрачу час на отладку неудачных тестов. И повтори это завтра утром и следующий обеденный перерыв.
Пока я не осознаю, что сейчас я провожу 2 часа в день, работая над исправлением тестов. Это 25% моего времени для работы над тестами, а не для меня.
Именно здесь я перестаю писать больше тестов, потому что вижу стоимость, а не ценность из них. И тогда я перестаю их запускать, потому что, какой в этом смысл?
Я называю это «
Спираль Смерти Судьбы»”, И многие разработчики, которые начинают проводить тестирование, падают вниз. Многие никогда не поднимаются снова.
Если мы перевернем процесс, мы увидим совершенно противоположное. Если мой пакет запускается в считанные секунды или быстрее, я запускаю его чаще. Когда тест перерыв, я знаю, что вызвало проблему, потому что я знаю, что это было вызвано изменениями, которые я сделал в последние несколько минут. Исправление может даже не потребовать отладки, потому что это все еще свежо в моей памяти. Развитие становится более плавным и быстрым.
Быстрая обратная связь обязательна
Тесты должны выполняться быстро. Мы говорим сотни и тысячи в считанные секунды. Если они этого не сделают, нам нужно что-то с ними сделать.
Быстрая обратная связь — это не только важное свойство Agile. Это важно для увеличения скорости. Если мы не будем работать над этим, вся система безопасности наших тестов может рухнуть.
Так что мы можем сделать?
- Анализ . Длина тестов является частью каждого отчета о тестировании, поэтому она даже не субъективна. Посмотрите на эти тесты и посмотрите, какие из них требуют больше времени для запуска.
- Организация . Разделите тесты, чтобы замедлить и быстро запустить. Оставьте медленный запуск более поздним автоматизированным циклом сборки, чтобы вы могли запускать быстрые без штрафа.
- Mock . Насмешка — отличный способ ускорить тестирование. Если зависимость (например, моя служба MSMQ) медленная, смейтесь над ней.
- Грум . Не все тесты должны быть частью нашей автоматической сборки навсегда. Если есть часть кода, которую вы никогда не трогаете, но у вас есть 5-минутный набор тестов, прекратите ее запуск. Или запустите тех на ночной цикл.
- Обновить. Вы будете удивлены, как быстрее ваше оборудование выполнит ваши тесты. Стоимость может быть незначительной по сравнению со значением быстрой обратной связи.
Ключевым моментом является постоянное обслуживание тестового набора. Продолжайте анализировать свой пакет, и вы увидите, где можно оптимизировать, не рискуя больше.
Результат — быстрая сеть безопасности, которой вы можете доверять.