Node.JS: тестовый код против организации производственного кода

Question

От беглого взгляда в нескольких проектах node.js на Github я заметил, что общим соглашением является размещение тестовых файлов в каталоге ./spec (точное название может отличаться: ./tests, ./specs , и т.д.). Назовем это «классической» организацией проекта.

С другой стороны, есть также (по крайней мере, теоретически) «локализация» организация: каждый тестовый файл находится в том же каталоге, что и файл производство тестируется (например, под ./controllers мы будем иметь login_controller.js, а также login_controller.spec.js).

Для того, чтобы избежать теологических сражения на этом явно субъективном тему I будет задать конкретные вопросы:

• Кто-нибудь видел основные модули/приложения с использованием локализующих организации?
• Существуют ли серьезные недостатки/ограничения для локализующей организации? «hard» я имею в виду что-то вроде «хорошо, Heroku не включает спецификацию/каталог в своем пакете развертывания (a.k.a slug), поэтому классическая организация имеет меньший след на сервере».
• Существуют ли рамки тестирования (Mocha, jasmine-node и co.), Которые каким-то образом навязывают «классическую» схему?

Answer 1

1. Нет, но это зависит от ваших организационных предпочтений. Я лично предпочел бы тестовый каталог.
2. Nope. Heroku включает в себя все в вашем slug, которое он получает, единственное, что исключено, - это те, которые были исключены из git в вашем файле .gitignore.
3. Не на 100% уверены, но, как правило, нет, тестовые рамки не накладывают структуру на ваш код. Они просто предоставляют инструменты для написания ваших тестов с использованием структуры, которую вы хотите.

Answer 2

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

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

2. Потенциальные проблемы с единичным испытательным бегуном. Большинство тестировщиков тестов показывают, что предпочитают папку тестов по умолчанию. Я уверен, что вы можете настроить , чтобы просмотреть весь проект, но это зависит от теста .

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

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