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

asyncFn предоставляет дополнительные методы, например. Jest.fn или sinon.spy, чтобы ввести позднее разрешение для обещаний, возвращаемых фиктивными функциями. Это упрощает модульное асинхронное тестирование, позволяя выполнять тесты в хронологическом порядке, как рассказ.

Отсюда мы получаем новую перспективу структурирования и написания модульных тестов.

Предисловие

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

Удачи, дорогой читатель.

Глава 1: Предпосылка и фундамент

Фрай: Меня зовут Фрай, и мне сложно выполнить модульное тестирование асинхронных материалов в JavaScript.

Лила, расскажите подробнее.

Фрай: Ага, допустим, я хотел кое-что реализовать в этой спецификации:

Фрай: круто то, что в этой игре запросы к действию от игрока асинхронны .

Лила: Мммм, думаю, я поняла. Давайте запачкаем руки и посмотрим, к чему это приведет.

Фрай: вот начальный тест на хорошую оценку:

На данный момент содержимое ./monsterBeatdown.js:

Лила: Пока все хорошо. Я вижу, вы решили внедрить фиктивную функцию для обмена сообщениями с игроком в качестве аргумента для функции, которую мы тестируем. Кристалл. Вперед на всех парах.

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

Глава 2: Проблемы возникают

Содержание ./monsterBeatdown.js на данный момент:

Лила: Держи трубку. Я вижу здесь две проблемы. Один - это дублирование , а другой - тест, описывающий вхождения в не хронологическом порядке , что затрудняет чтение теста. Начнем с решения первой проблемы.

Глава 3: Неуклюжее исправление

Фрай: Я все равно собирался удалить дубликаты. Красный-зеленый-рефакторинг, верно?

Лила: Верно.

На данный момент содержимое ./monsterBeatdown.js:

Фрай: Вот. Теперь дублирование тестовой установки убрано, но лишь частично. Однако другая проблема, заключающаяся в том, что тесты не записываются в хронологическом порядке, мешает нам удалить все дублирование. Посмотрите, как нас заставляют повторять game.encounterMonster(), потому что askPlayerToHitMock нужно знать, как себя вести, прежде чем он будет вызван.

Что еще хуже, это делает «описание» нечестным, поскольку оно утверждает, что показывает, как "given a monster is encountered", но на самом деле это то, что происходит только позже в тестовой настройке, если вообще когда-либо.

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

Лила: Понятно. Давайте теперь представим asyncFn как расширение к обычному jest.fn для решения всех проблем.

Вот.

Глава 4: Взгляд на asyncFn

Содержание ./monsterBeatdown.js на данный момент:

Лила: Теперь дублирования больше нет, и все происходит в чистом хронологическом порядке. Это похоже на историю, не правда ли?

Фрай: Мммм. Я вижу это. У меня хорошее предчувствие. Но что-то меня беспокоит с производственным кодом. Я вижу, что тесты все зеленые, но код ничего толкового явно не делает. Он просто проходит, просто удовлетворяя тесты.

Лила: Вы меня там поймали. Фактически мы занимаемся чем-то, что называется « злым спариванием ». Если вы хотите сформировать производственный код по-своему, вам нужно заказать его из юниверса, написав сначала тест.

Позвольте мне показать вам, как это сделать.

Глава 5: Зло - это хорошо, а отрицательное - положительно

Содержание ./monsterBeatdown.js на данный момент:

Лила: Вот. Я уменьшил «вредоносность» кода, добавив то, что мы называем «тестами отрицания». Написав тесты, описывающие то, что не должно произойти, мы заставили производственный код сделать немного более понятным.

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

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

В общем, эта «злая пара-менталитет» помогает создавать код, который очень надежен для рефакторинга, а также позволяет программистам еще немного отточить свое TDD-mojo.

Но я отвлекся. Каким бы важным это ни было, это немного отклоняется от курса. Важно то, что asyncFn поддерживает злые пары как образ мышления .

Давай, мотор!

Глава 6: Вызов множественности и просветление

Фрай: Конечно. Можем ли мы увидеть, как игра будет развиваться дальше? В частности, я страдал от тестирования функций, которые вызываются несколько раз , но все же возвращают обещания.

Лила: Я чувствую тебя. Я предполагаю, что asyncFn-mock будет вызываться несколько раз достаточно скоро, когда мы начнем атаковать монстра несколько раз.

Посмотрим, что из этого получится.

Содержание ./monsterBeatdown.js на данный момент:

Лила: Вот. Теперь монстр получает несколько ударов, при этом все происходит в четком порядке. Наша работа здесь закончена.

Фрай: цвет меня просветленный. Это изменило мой взгляд на мир как программиста и человека. Я принесу жертвы в вашу честь и сделаю татуировку asyncFn. Мои внуки будут знать ваше имя.

Резюме

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

asyncFn - это то, что мы, как команда, используем уже несколько лет. Это категорически изменило наш подход к модульному тестированию асинхронного кода в JavaScript. Которые мы так обожаем.

См. Подробнее об asyncFn для слов шутка или синон.

Кто мы?

asyncFn с любовью создан вашими друзьями из Team: Igniter из Houston Inc. Consulting.

Мы - команда друзей по разработке программного обеспечения с проверенными традициями профессионального мастерства. Мы специализируемся на комплексном быстром развертывании без ущерба для качества.

Приходите поздороваться в Gitter, напишите нам или ознакомьтесь с самой командой. Мы просто можем быть доступны для найма;)