Разработка на основе тестов Meteor [закрыто]

Я не понимаю, как проводить разработку через тестирование в Meteor.

Я нигде не упоминаю об этом в документации или FAQ. Я не вижу примеров или чего-то подобного.

Я вижу, что некоторые пакеты используют Tinytest.

Мне нужен ответ от разработчиков, какова дорожная карта по этому поводу. Что-то вроде:

• возможно, документации нет, разберитесь сами
• Meteor не создан таким образом, чтобы вы могли создавать тестируемые приложения
• это запланированная функция
• и т.д

Обновление 3 : Начиная с версии Meteor 1.3, meteor включает руководство по тестированию с пошаговыми инструкциями по модульному, интеграционному, приемочному и нагрузочному тестированию.

Обновление 2 : с 9 ноября 2015 года Velocity больше не поддерживается . Xolv.io сосредотачивает свои усилия на Chimp , и Meteor Development Group должна выбрать официальную среду тестирования .

Обновление : Velocity - это официальное решение для тестирования Meteor, начиная с версии 0.8.1.

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

Хорошие новости: вы можете использовать инструменты тестирования Node.js с Meteor .

Для своего проекта Meteor я запускаю модульные тесты с Mocha, используя Chai для утверждений. Если вам не нужен полный набор функций Chai, я рекомендую использовать вместо него should.js . На данный момент у меня есть только модульные тесты, хотя вы также можете писать интеграционные тесты с помощью Mocha.

Обязательно поместите свои тесты в папку «tests», чтобы Meteor не пытался выполнить ваши тесты.

Mocha поддерживает CoffeeScript , язык сценариев, который я выбрал для проектов Meteor. Вот образец файла Cakefile с задачами для запуска ваших тестов Mocha. Если вы используете JS с Meteor, не стесняйтесь адаптировать команды для Makefile.

Ваши модели Meteor потребуют небольшой модификации, чтобы они были доступны для Mocha, а для этого потребуется некоторое знание того, как работает Node.js. Считайте, что каждый файл Node.js выполняется в пределах своей собственной области действия. Meteor автоматически предоставляет друг другу объекты в разных файлах, но обычные приложения Node, такие как Mocha, этого не делают. Чтобы сделать наши модели доступными для тестирования с помощью Mocha, экспортируйте каждую модель Meteor с помощью следующего шаблона CoffeeScript:

# Export our class to Node.js when running
# other modules, e.g. our Mocha tests
#
# Place this at the bottom of our Model.coffee
# file after our Model class has been defined.
exports.Model = Model unless Meteor?

... и в верхней части вашего теста Mocha импортируйте модель, которую вы хотите протестировать:

# Need to use Coffeescript's destructuring to reference
# the object bound in the returned scope
# http://coffeescript.org/#destructuring
{Model} = require '../path/to/model'

После этого вы можете начать писать и запускать модульные тесты с вашим проектом Meteor!

Привет всем, оформление заказа laika - полностью новый фреймворк для тестирования Meteor http://arunoda.github.io/laika/

Вы можете протестировать и сервер, и клиент одновременно.

• См. Пример лайки здесь
• Смотрите здесь функции
• Посмотреть концепцию лайки
• См. Репозиторий Github

Отказ от ответственности: я автор Лайки.

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

Я занимался разработкой приложений с Meteor, а также разработкой пакетов, как путем реализации пакета для ядра Meteor, так и для атмосферы .

Похоже, ваш вопрос может состоять из трех частей:

1. Как запустить весь набор тестов Meteor?
2. Как писать и запускать тесты для отдельных смарт-пакетов ?
3. Как написать и запустить тесты для собственного приложения?

И, похоже, где-то там может быть бонусный вопрос: 4. Как можно реализовать непрерывную интеграцию для 1, 2 и 3?

Я разговаривал и начал сотрудничать с Наоми Сейфер (@sixolet) в основной команде Meteor, чтобы помочь получить окончательные ответы на все эти вопросы в документации.

Я отправил первоначальный запрос на перенос с адресацией 1 и 2 в ядро ​​метеора: https://github.com/meteor/meteor/pull/573 .

Я также недавно ответил на этот вопрос: как запустить метеорные тесты?

Я думаю, что @Blackcoat окончательно ответил на пункт 3 выше.

Что касается бонуса 4, я бы предложил использовать circleci.com, по крайней мере, для непрерывной интеграции ваших собственных приложений. В настоящее время они поддерживают вариант использования, описанный @Blackcoat. У меня есть проект, в котором я успешно получил тесты, написанные на coffeescript, для запуска модульных тестов с мокко, примерно так, как описал @Blackcoat.

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

RTD устарел и заменен Velocity, который является официальной средой тестирования для Meteor 1.0. Документация все еще относительно новая, так как Velocity находится в стадии интенсивной разработки. Вы можете найти дополнительную информацию о репозитории Velocity на Github , домашней странице Velocity и руководстве по тестированию Meteor (платный контент)

Отказ от ответственности: я один из основных членов команды Velocity и автор книги.

Проверьте RTD, полную среду тестирования для Метеора здесь rtd.xolv.io . Он поддерживает Jasmine / Mocha / custom и работает как с обычным JS, так и с кофе. Он также включает в себя тестовое покрытие, которое сочетает в себе покрытие модуля / сервера / клиента.

И пример проекта здесь

Блог с объяснением модульного тестирования с помощью Meteor здесь

Подход к приемочному тестированию e2e с использованием Selenium WebdriverJS и Meteor здесь

Надеюсь, это поможет. Отказ от ответственности: я являюсь автором RTD.

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

Начать работу с этим решением действительно просто, если оно еще не полностью задокументировано, поэтому я рекомендую его людям вроде меня, которые хотят использовать TDD, но не знают, как работает тестирование в JavaScript и какие библиотеки к чему подключаются:

https://github.com/mad-eye/meteor-mocha-web

К вашему сведению, я обнаружил, что мне также нужно использовать пакет Router Atmosphere для создания маршрута «/ tests» для запуска и отображения результатов тестов, поскольку я не хотел, чтобы он загромождал мое приложение каждый раз при его загрузке.

Что касается использования tinytest, вы можете взглянуть на эти полезные ресурсы:

1. Основы объясняются в этом скринкасте: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. Как только вы поймете идею, вам понадобится документация по общедоступному API для tinytest. На данный момент единственная документация для этого находится в конце исходного кода tinytestпакета: https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Кроме того, в скринкасте говорится о том test-helpers, что вы можете посмотреть здесь все доступные помощники: https://github.com/meteor/meteor/tree/devel/packages/test-helpers Часто внутри каждого есть некоторая документация. файл

4. Покопавшись в существующих тестах пакетов Meteor, можно найти множество примеров. Один из способов сделать это - выполнить поиск Tinytest.или test.в каталоге пакетов исходного кода Meteor.

Тестирование станет основной частью Meteor в следующем выпуске 1.3. Первоначальное решение основано на Mocha и Chai.

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

Компания MDG создала исходную основу руководящей документации по тестированию, которую можно найти здесь , и здесь есть несколько примеров тестов .

Это пример теста публикации по ссылке выше:

  it('sends all todos for a public list when logged in', (done) => {
    const collector = new PublicationCollector({userId});
    collector.collect('Todos.inList', publicList._id, (collections) => {
      chai.assert.equal(collections.Todos.length, 3);
      done();
    });
  });

Я провожу функциональные / интеграционные тесты с Meteor + Mocha в браузере. У меня есть что-то вроде следующего (в coffeescript для лучшей читаемости):

На клиенте ...

Meteor.startup ->
    Meteor.call 'shouldTest', (err, shouldTest) ->
        if err? then throw err
        if shouldTest then runTests()

# Dynamically load and run mocha. I factored this out in a separate method so
# that I can (re-)run the tests from the console whenever I like.
# NB: This assumes that you have your mocha/chai scripts in .../public/mocha.
# You can point to a CDN, too.
runTests = ->
    $('head').append('<link href="https://stackoverflow.com/mocha/mocha.css" rel="stylesheet" />')
    $.getScript '/mocha/mocha.js', ->
      $.getScript '/mocha/chai.js', ->
        $('body').append('<div id="mocha"> </div>')
        chai.should() # ... or assert or explain ...
        mocha.setup 'bdd'
        loadSpecs() # This function contains your actual describe(), etc. calls.
        mocha.run()

... и на сервере:

Meteor.methods 'shouldTest': -> true unless Meteor.settings.noTests  # ... or whatever.

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

Как сказал Blackcout, Velocity - это официальный фреймворк TDD для Meteor. Но на данный момент веб-страница скорости не предлагает хорошей документации. Так что рекомендую посмотреть:

• Концепция скорости
• Пошаговое руководство
• И особенно официальные примеры

Другой вариант, который стал легко доступным с версии 0.6.0, - это запуск всего вашего приложения из локальных интеллектуальных пакетов с минимальным количеством кода вне пакетов для загрузки вашего приложения (возможно, вызов определенного интеллектуального пакета, который является основой вашего приложение).

Затем вы можете использовать Tinytest от Meteor, который отлично подходит для тестирования приложений Meteor.

Я успешно использовал xolvio: cucumber и скорость для тестирования. Работает очень хорошо и работает постоянно, поэтому вы всегда можете видеть, что ваши тесты проходят успешно.

Метеор + TheIntern

Как-то мне удалось протестировать приложение Meteor с TheIntern.js.

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

Существует executeфункция, которая позволяет нам запускать JS-код, через который мы можем получить доступ к windowобъекту браузера и, следовательно, Meteorтакже.

Хотите узнать больше о выполнении

Вот как я test suiteсмотрю на функциональное тестирование

define(function (require) {
    var registerSuite = require('intern!object');
    var assert = require('intern/chai!assert');
    registerSuite({
        name: 'index',

        'greeting form': function () {
            var rem = this.remote;
            return this.remote
                .get(require.toUrl('localhost:3000'))
                .setFindTimeout(5000)
                .execute(function() {
                        console.log("browser window object", window)
                        return Products.find({}).fetch().length
                    })
                .then(function (text) {
                    console.log(text)
                    assert.strictEqual(text, 2,
                        'Yes I can access Meteor and its Collections');
                });
        }
    });
});

Чтобы узнать больше, это моя суть

Примечание. Я все еще нахожусь на очень ранней стадии разработки этого решения. Я не знаю, смогу ли я провести с этим комплексное тестирование или нет. Но я почти уверен в этом.

Скорость еще не созрела. Я столкнулся с проблемами setTimeout, чтобы использовать скорость. Для модульного тестирования на стороне сервера вы можете использовать этот пакет .

Это быстрее скорости. Velocity требует огромного времени, когда я тестирую любую спецификацию с логином. С помощью кода Jasmine мы можем протестировать любой метод и публикацию на стороне сервера.