Свежий взгляд на тестирование Node.js проекты: Mocha, Should и Travis
Сегодня я, наконец, решила провести немного времени с Трэвисом. Прошло несколько недель с тех пор, как маленькая зеленая картинка на главной странице GitHub не давала мне покоя. Что ж, если быть до конца честной, я не так начала свой вечер. Во-первых, после 2-х лет добросовестной работы я решил отказаться от кофе Expresso и дал шанс Mocha. Потому что Expresso обогащает модуль assert одной или двумя функциями, к которым я пристрастился. Мне также пришлось искать те же функции в другой библиотеке утверждений, что привело меня к тестированию Should. Очень приятно видеть, что эти две библиотеки работают вместе, как в традициях Unix: компактные, мощные и естественно интегрированные.
Mocha, написанный тем же автором, что и Expresso, призван заменить его. Так было уже довольно давно, но я всегда неохотно приступал к BDD-тестированию. BDD расшифровывается как Behavior Driven Development и является альтернативным способом выражения ваших тестов. Например, названия тестов могут быть представлены в виде полного предложения. Его цель — стимулировать сотрудничество между разработчиками, специалистами по контролю качества и нетехническими или бизнес-участниками в рамках проекта по разработке программного обеспечения. Возможно, это применимо в некоторых рабочих областях, но, исходя из личного опыта, мы не можем ожидать, что наши клиенты будут участвовать в тестировании. Cucumber, вероятно, самый популярный инструмент BDD, у него есть свои поклонники, но в прошлом я был слишком ленив, чтобы переходить на BDD. Сталкиваясь с любым образцом, возникает ощущение, что вы учите новый язык для написания тестов. Возможно, это было ошибочное впечатление, и это может оказаться намного проще, чем я думаю.
Теперь давайте взглянем на Mocha. API довольно прост, в основном это две функции — describe и it. Обе они принимают текст в качестве первого аргумента, который, объединяясь, создает приятное предложение во время выполнения. Пример:
опишите «Мой тест», -> он «должен выполняться синхронно», () -> # что делать, если он «должен выполняться асинхронно», (далее) -> # что делать дальше()
Обратите внимание, как Mocha обнаруживает, и давайте еще решим, стоит ли вам хотите ли вы запускать свои тесты синхронно или нет, даже смешивая эти два режима. По сути, в нем используется не столь популярное свойство length, связанное с функцией. Есть несколько дополнительных методов, которые пригодятся для изменения настроек, а также для настройки и очистки ваших тестов. В качестве иллюстрации приведу пример, взятый из набора тестов mecano:
should = требуется «should» mecano = требуется «mecano» для описания «загрузки», -> @beforeEach (следующий) -> mecano.mkdir с нуля, далее @afterEach (следующий) -> mecano.rm scratch, далее он «должен иметь дело со схемой ftp», (далее) -> @timeout 10000 mecano.источник загрузки: ‘ftp://ftp.gnu.org/gnu/glibc/README.glibc ‘ пункт назначения: «#{scratch}/download_test» , (ошибка, загружено) -> должно.не.существовать, ошибка, загружено.should.eql 1 next()
Функции beforeEach и afterEach позволяют выполнять код до и после каждого теста. Функция timeout изменяет максимальное время выполнения теста (по умолчанию 2 секунды).
Здесь давайте рассмотрим использование функции Should.js. Ее назначение, как и любой библиотеки утверждений, заключается в обнаружении некорректно возвращаемой переменной. На первый взгляд, API в стиле BDD может показаться сложным, но я нашел его естественным, и мне не пришлось с ним бороться. Что ж, я все сказал. По сути, это то, чего я ожидаю от такой библиотеки, а не открывать браузер, чтобы разобраться, как использовать API. После 10 миллионов использования, должен.js показал себя простым, выполнил свои обещания и улучшил читаемость кода (на мой взгляд).
Наконец, я решил разобраться с этим статусом Travis. Вывести изображение на страницу mecano на GitHub было просто. Настройка Travis и интеграция с GitHub для новичка заняли менее 15 минут. Чтобы сделать его зеленым, потребовалось немного больше времени. При запуске теста Mecano делает несколько предположений. Он должен быть подключен к сети, у него должен быть установлен GIT и возможность подключаться к SSH. Оказывается, при первом запуске я был приятно удивлен, что только 5 тестов не прошли успешно. Большинство из них были моей ошибкой, и я исправил их. Еще один был должен.js использует JavaScript, который был несовместим с тем, который использовался в Node.js в версии “0.4”. Из-за этого у меня осталась только одна проблема — настроить учетную запись пользователя Travis таким образом, чтобы она могла подключаться к SSH без запроса пароля. В итоге, мой конфигурационный файл “.travis.yml” выглядит следующим образом:
язык интерфейса: node_js, node_js: — 0.6 — 0.7, before_script: — «ssh-keygen -t rsa -f ~/.ssh/id_rsa -N «» — «cat ~/.ssh/id_rsa -N «» — «cat ~/.id_rsa -N «» — «cat ~/..pub > ~/.ssh/authorized_keys»
Во время этой презентации я не давал никаких инструкций, связанных с установкой и настройкой, поскольку каждый проект очень хорошо документирован. Спасибо авторам этих инструментов за их замечательную работу.
Другие новости: