В настоящее время я смотрю в рамки метеор, и этот вопрос сразу же подскакивает. Является ли код, который я пишу (например, Template.xxx code или Template.xxx.events), фактически проверяемым каким-либо образом?
Конечно, вы можете протестировать код, который не связан со временем выполнения метеорита, как и любой другой код, но мое впечатление заключается в том, что большинство кода, который вы напишете внутри метеор, каким-то образом охвачены метеор и его функциями.
По состоянию на февраль 2014 года код Meteor можно тестировать с помощью встроенной Tinytest, если вы переместите все свои код приложения в пакеты, который вы должны делать в любом случае. Быстрый и грязный способ заключается в добавлении файла package.js. Этот файл служит для:
Вот пример Eventedmind - https://github.com/EventedMind/meteor-file
Вы можете увидеть в meteor-file-test.js, что он обращается к MeteorFile, который объявлен как экспорт в package.js.
Кажется, что никакой официальной тестовой структуры пока нет, кроме недокументированный Tinytest (см. видеоурок) и helpers, но вы всегда можете заглушить/API-интерфейс Meteor, как я сделал в этом тривиальном примере на github.
Я предполагаю, что это может стать намного сложнее для нетривиальных приложений, поэтому, вероятно, неплохо отделить основную логику приложений от вызовов API Meteor.
Я думаю, что это можно проверить, хотя я не слишком глубоко заглядывал в него.
Если вы откроете пакет liveui ($METEOR_HOME/packages/liveui), то, по-видимому, будет проведено несколько отдельных тестов с использованием TinyTest и тестирования рендеринга. Я думаю, что было бы неплохо начать: -
и др.
Надеюсь, что поможет
Я создал сообщение в блоге, в котором показано, как сделать эффективное модульное тестирование в Meteor, а также пример проекта GitHub. Надеюсь, что это поможет.
Velocity была выбрана в качестве официальной платформы тестирования для метеора 1.0. Объявление было сделано в последнем метеорном магазине (июнь 2014 г.).
Пакеты, разработанные со скоростью: