Как правильно организовать процесс написания и тестирования клиентского JavaScript-кода?

Question

[Денис Малиночкин]

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

Сразу скажу, что перед тем, как задать вопрос я пользовался Google, читал статьи и искал похожий код в репозиториях на GitHub. К сожалению, вся найденная мной информация не описывает работу именно с DOM, а, в основном, затрагивает тему калькулятора.

Задача

Допустим, у меня есть три модуля, написанные на ES2015 без использования каких-либо фреймворков: класс табов, меню и поиска. Каждый модуль использует некоторые вспомогательные методы из класса хелперов для работы с DOM (как вариант).

Вопросы

• Нормальна ли схема с единой точкой входа, где все модули импортируются и вызываются в app.js? — ведь, если количество модулей перевалит за 10, то код в app.js будет весьма посредственным и раздутым.
  
  
• Если используется единая точка входа app.js, то вешать события на элементы (делигирование и проче) стоит осуществлять в этом файле или в модулях?
  
  
• Как тестировать такой код? Если на Node.js я могу просто подключать модули туда-сюда и писать тесты на mocha или Ava, то как с этим дела обстоят здесь? Пока я вижу следующую схему: mocha + jsdom (имплементация DOM для Node.js). Схема весьма удобна, но вызывает вопросы в том случае, если модули зависят друг от друга — в таком случае я должен сначала собрать бандл, а уже потом тестировать свой код. Я правильно понимаю этот момент? Например, в Bootstrap тестируют код прямо в браузере, но там слегка попроще, потому что используется родная связка jQuery + Qunit. Или стоит создать отдельную страницу, на которой будут запускаться тесты mocha на основе уже собранного JS проекта?
  
  
• Читал про PhantomJS и построенный на нём CasperJS, но, если моя функция не предназначена для работы с DOM — я должен снова вернуться к unit-тестам.
  
  
• Имеет ли вообще смысл тестировать, скажем так, такой примитивный код? Речь идёт даже о тех случаях, когда, допустим, добавляются несколько модулей для работы с автокомплитом, поиском и т.д.
  

Собственно, прошу помощи, ибо каждая вторая статья, что находится по запросу тестирования клиентского JS-кода приводит меня к теме тестирования React/Angular/калькулятор. Возможно у кого-то завалялся репозиторий с похожим кейсом? — я бы с радостью посмотрел на код.

Спасибо за внимание и, надеюсь на понимание.

Answer 1

[Сергей Протько]

Нормальна ли схема с единой точкой входа

В принципе нормально, все так и делают вобщем то.

ведь, если количество модулей перевалит за 10

Всегда можно вынести что-то в отдельный модуль. Руководствуйтесь здравым смыслом, снижайте связанность (вообще почитайте про low coupling и high cohesion для более адекватной организации модулей).

вешать события на элементы

А ваши модули с табами и т.д. что делают тогда?

Или стоит создать отдельную страницу, на которой будут запускаться тесты mocha на основе уже собранного JS проекта?

Это наиболее удобный вариант. Так же помимо фэнтома рассмотрите вариант с webdriver io, как самый честный вариант тестирования. Медленно... но чтож поделать если вы решили UI тестить (а точнее UI элементы).

Пока я вижу следующую схему: mocha + jsdom

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

если моя функция не предназначена для работы с DOM — я должен снова вернуться к unit-тестам.

Именно так. Если вам не нужен DOM - старые добные юнит тесты.

Имеет ли вообще смысл тестировать, скажем так, такой примитивный код?

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

Возможно у кого-то завалялся репозиторий с похожим кейсом?

Рекомендую вам просто отказаться от прямой работы с DOM. Мне дико нравится подход ангуляра к построению приложений. В нем мы тестируем 10% директив, которым приходится работать с DOM, а все остальное - просто подготовка состояния. Далее в дело вступают биндинги, которые и так оттестированы, и декларативное представление, которое по природе своей тестировать смысла нет.

Comments

[Денис Малиночкин]

Спасибо за ответ. Почти всё встало на свои места — нужно будет подробнее почитать о PhantomJS. Касательно ваших вопросов и предложений:

• А ваши модули с табами и т.д. что делают тогда? — я предполагал, что вся логика работы будет находиться в этих модулях, а работа с событиями будет находиться рядом с вызовом. Хотя да, признаю, я написал глупость.
  
• Рекомендую вам просто отказаться от прямой работы с DOM. — что вы имеете в виду, если речь идёт, скажем, не о больших объёмах JavaScript-кода? В таком случае тот же Angular тащить за собой я не вижу смысла. Например, если речь идёт об админке сайта (или о самом сайте), где от JavaScript-кода всего будет максимум 10 модулей.