Я запустил приложение и с радостью просмотрел количество дней до Рождества, впечатлив своих детей своей гениальностью. Тогда Джули, мои партнеры, спросила меня: действительно ли осталось «39 дней» до Рождества?

Поэтому я спросил Google. Кто ответил, что было 40 дней. Поэтому я спросил Алексу, и она сказала, что тоже 40 дней. Возможно, в моем коде была ошибка…

Однако без тестов я понятия не имел, кто был прав (но, признаем, это был я). Мой код включал простую разность дат (используя moment.js):

const xmas = moment([new Date().getYear() + 1900, 11, 25]);
const days = xmas.diff(moment(), 'days'); // looks legit…

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

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

const days = xmas.diff(moment().startOf('day'), 'days'); // 👍

Лучше. Но хоть это и исправлено, тестов там до сих пор нет…

Урок 2: всегда есть минимум

Если я работаю над приложением, которое имеет единственную цель, например, показать количество дней до Рождества, то очень важно иметь по крайней мере один тест, подтверждающий правильность этой цифры.

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

Так что это урок для меня, но, пожалуйста, прислушайтесь к моему предупреждению: проверяйте минимум!

Вот моя стратегия тестирования в начале этого года, если вам интересно, как это сделать.

Урок 3: тестирование может привести к важным вопросам

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

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

Тесты позволяют мне эмулировать эти факторы (в некоторых случаях). Я видел твит с моим приложением обратного отсчета к Рождеству во всей его красе, которым пользуется кто-то в Швейцарии:

… что сразу же приводит меня к вопросу: в каком часовом поясе работает мой код?

Устройство LaMetric сделает вызов API к моему сервису обратного отсчета, но сервис не знает, в какой стране находится пользователь. Я использую машину, системные часы которой установлены на UTC, что меня вполне устраивает, и, вероятно, большинство европейских стран этого не заметят, но если кто-нибудь из Сан-Франциско воспользуется моими часами в 16:00 в канун Рождества, он увидит, что часы переводятся на 0 дней! и они увидят Санту вместо мигающей елки.

Урок: всегда включайте хотя бы тест.

Второй урок: никогда не работайте с животными, детьми или временем!

Первоначально опубликовано в журнале Remy Sharp’s b:log