The future of Node.js: Stable, secure, everywhere

За последнии 4 года разработка на платформе Node.js резко возросла, по данным Node.js Foundation и трендам google. Разработчики отмечают основные приоритеты Node.js, как стабильность и безопасность, и проводят множество исследовательских работ в рамках многопоточности.

Сообщество Node.js все больше пытается популяризировать использование технологии в рамках серверных разработок и интернета. Одним из последних докладчиков стал Rod Vagg, член Node Technical Steering Committee, который представил доклад на Node Summit conference в San Francisco.

Хотите разрабатывать на JavaSciprt ? Взгляните на 17 JavaScript editors and IDEs.

Сообщество и разработчики Node.js стремятся к стабильность релизов. Vagg отметил в своем докладе, — «К сожалению, мы привыкли называть текущую ветку Node.js — стабильной, однако она далека от той стабильности, которой мы бы хотели достичь». За последнии релизы было слишком много дефектов и регрессии. Например, одна из последних статей «The Node.js Foundation revealed a denial-of-service and an out-of-bounds access issue and said the fixes will come next week». Ситуация не критична, но нуждается в улучшении.

В будущих улучшениях языка планируется добавление Zones, для более удобного написания асинхронного кода. Между тем и многопоточность может быть реализована аналогично с браузерами поддерживающими Web Workers.

Так же в планах есть улучшение взаимодействий между Node.js и ECMA TC39 комитетом, который занимается разработкой стандарта ECMAScript. Опять таки более тесная связь с ECMA TC39 поможет улучшить построение асинхронных процессов. И в недалеком будущем обещают реализацию низкоуровневых функций JavaScript tail call, что поможет более удобной отладки кода.

И конечно не обходится без планов на внедрение HTTP/2. При этом не стоит забывать сколько в Node.js было уязвимостей связанных HTTP.

Одним из самых интересных планов является обновление движка V8 при соблюдении стабильность ABI. Google’s V8 JavaScript текущий выбор VM для Node.js, но Microsoft в надежде угнаться за динамичность развивающейся областью — бросается в погоню.

Unit, Integration and Functional Testing

В среде тестирования JavaScript зачастую бывает сложно с ориентироваться в точном понимание терминов тестирования, таких как unit tests, integration tests, functional tests, E2E tests, browser tests… Кто за что отвечает и какой из них использовать, зачем и когда ?

Unit Testing

Unit tests или еще модульное тестирование, является практикой тестирования небольших фрагментов кода, изолированных функций. Если ваши тесты используют сторонние ресурсы, например сетевые ресурсы или обращение к базе данных, то это не относится к данному классу тестов.

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

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

Когда же следует использовать модульное тестирование ? В идеале на протяжении всего времени работы над проектом. Хороший набор модульных тестов позволяет не только предотвратить возникновение ошибок, но и улучшить дизайн кода  и в дальнейшем помочь в реорганизации («рефакторинге») кода.

Одни из популярных инструментов являются Mocha и Jasmine test framework.

Integration Testing

Как следует из названия, в интеграционном тестирование идея заключается в том, чтобы проверить совместность работы компонентов системы. Интеграционные тесты аналогичны модульным тестам, но есть одна большая разница: если модульные тесты изолированы о знании окружающих компонентов, то интеграционные — нет. Например, модульный тест не будет делать реальный запрос к API сервера, в свою очередь интеграционный тест будет.

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

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

Для написания интеграционных тестов (в рамках JavaScript) обычно используются те же инструменты, что и для модульных.

Functional Testing

Функциональные тесты иногда называют E2E тестами или тестированием браузера.

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

Вы можете использовать модульные тесты для проверки изолированной логики функций или интеграционные тесты, для проверки взаимодействия компонентов. Функциональные тесты строятся уровнем выше. При наличии сотни модульных тестов, функциональных обычно в 10 раз меньше. Это связанно со сложностью их написания и долгим временем их выполнения, т.к. данные тесты имитируют реальное поведение системы.

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

Наиболее распространенным инструментом используемым для функционального тестирование является Selenium. Запуск Selenium обычно осуществляется с помощью Selenium WebDriver или Protractor. Если вам нет необходимость использовать реальный браузер, то можно воспользоваться PhantomJS или CasperJS.

В заключение

Модульное тестирование является основной JavaScript тестов. Данные тесты просты в написание и поддержке, и обеспечивают путь к уменьшению дефектов приложения. Интеграционные и функциональные тесты используются в тех областях, где модульные тесты не подходят.

 

Полезные ссылки

How to access Angular $log debug messages from within Karma

;TLDR
Если вам по какой-то случайности в исполнении unit тестов захочется увидеть вывод логов в консоле, то это решение может быть полезно.

Angular $log

Angular имеет внутренний сервис $log, который позволяет формировать отладочные сообщения в консоли браузера:

The cool thing about debug messages is that you can easily turn logging on/off in one place using the $logProvider:

Сообщения от данного сервиса можно легко отключить на глобальном уровне всего приложения использую $logProvider:

Тем самым мы получаем возможность легко управлять лавированием приложения в разных окружениях — production, stage, develop.

Проблемы с Karma тестами

Однако при запуски unit тестов с Karma, вы уже не увидите ранее знакомых логов  в консоле:

Перечитывая документацию Karma вы конечно найдете:

и это никак не повлияет на вывод логов сервиса Angular, данные параметры конфигурации применимы только к легированную внутренней работы Karma.

Решение

Причиной отсутсвия сообщений логов является angular-mocks, точнее содержащийся в нем переопределенный методы $logProvider, который отлавливает все сообщения и собирает в один массив.

Теперь, чтобы вывести накопленные сообщения:

в консоле при запуске Karma