유성 테스트 주도 개발

유성 테스트 주도 개발

---

유성에서 테스트 중심 개발을 수행하는 방법을 모르겠습니다.

설명서 또는 FAQ의 어느 곳에서도 언급되지 않았습니다. 예나 그와 비슷한 것을 보지 못했습니다.

일부 패키지는 Tinytest를 사용하고 있습니다.

개발자의 답변이 필요합니다. 이것에 관한 로드맵은 무엇입니까? 다음과 같은 내용이 있습니다.

• 가능하고 문서가 없으며 스스로 알아 내십시오.
• 유성은 테스트 가능한 앱을 만들 수있는 방식으로 구축되지 않았습니다.
• 이것은 예정된 기능입니다
• 기타

---

업데이트 3 : Meteor 1.3부터 ​​meteor에는 단위, 통합, 승인 및로드 테스트에 대한 단계별 지침이 포함 된 테스트 가이드 가 포함되어 있습니다.

업데이트 2 : 2015 년 11 월 9 일부터 Velocity는 더 이상 유지되지 않습니다 . Xolv.io는 Chimp에 노력을 집중 하고 있으며 Meteor Development Group은 공식 테스트 프레임 워크를 선택해야합니다 .

업데이트 : Velocity 는 0.8.1부터 Meteor의 공식 테스트 솔루션 입니다.

---

현재 Meteor의 자동 테스트에 대해서는 많이 언급되지 않았습니다. 공식 문서에 무엇이든 설정하기 전에 Meteor 커뮤니티가 테스트 모범 사례를 발전시킬 것으로 기대합니다. 결국, Meteor는 이번 주에 0.5에 도달했으며, 상황은 여전히 ​​빠르게 변하고 있습니다.

좋은 소식 : Meteor와 함께 Node.js 테스트 도구 를 사용할 수 있습니다 .

Meteor 프로젝트의 경우 Chai 를 사용하여 어설 션에 대해 Mocha로 단위 테스트를 실행 합니다. Chai의 전체 기능 세트가 필요하지 않으면 should.js를 대신 사용하는 것이 좋습니다 . 지금은 단위 테스트 만 있지만 Mocha와의 통합 테스트도 작성할 수 있습니다.

확인하는 폴더에 "테스트"에 테스트를 배치 그래서 유성이 테스트를 실행하지 않습니다.

Mocha는 Meteor 프로젝트를위한 스크립트 언어 인 CoffeeScript를 지원합니다 . 다음 은 Mocha 테스트 실행을위한 작업 이 포함 된 샘플 Cakefile 입니다. Meteor와 함께 JS를 사용하는 경우 Makefile에 대한 명령을 자유롭게 적용하십시오.

Meteor 모델은 Mocha에 노출되도록 약간의 수정이 필요하며 Node.js의 작동 방식에 대한 지식이 필요합니다. 각 Node.js 파일은 자체 범위 내에서 실행되는 것으로 생각하십시오. Meteor는 다른 파일의 객체를 서로 자동으로 노출하지만 Mocha와 같은 일반적인 Node 응용 프로그램은이 작업을 수행하지 않습니다. 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?

... 모카 테스트 상단에서 테스트하려는 모델을 가져옵니다.

# 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 프로젝트에서 단위 테스트 작성 및 실행을 시작할 수 있습니다!

---

모든 체크 아웃 라이카 안녕 -유성에 대한 완전히 새로운 테스트 프레임 워크 http://arunoda.github.io/laika/

서버와 클라이언트를 한 번에 테스트 할 수 있습니다.

• See some laika example here
• See here for features
• See concept behind laika
• See Github Repository

Disclaimer: I'm the author of Laika.

---

I realize that this question is already answered, but I think this could use some more context, in the form of an additional answer providing said context.

I've been doing some app development with meteor, as well as package development, both by implementing a package for meteor core, as well as for atmosphere.

It sounds like your question might be actually a question in three parts:

1. How does one run the entire meteor test suite?
2. How does one write and run tests for individual smart packages?
3. How does one write and run tests for his own application?

And, it also sounds like there may be a bonus question in there somewhere: 4. How can one implement continuous integration for 1, 2, and 3?

I have been talking and begun collaborating with Naomi Seyfer (@sixolet) on the meteor core team to help get definitive answers to all of these questions into the documentation.

I had submitted an initial pull request addressing 1 and 2 to meteor core: https://github.com/meteor/meteor/pull/573.

I had also recently answered this question: How do you run the meteor tests?

I think that @Blackcoat has definitively answered 3, above.

As for the bonus, 4, I would suggest using circleci.com at least to do continuous integration for your own apps. They currently support the use case that @Blackcoat had described. I have a project in which I've successfully gotten tests written in coffeescript to run unit tests with mocha, pretty much as @Blackcoat had described.

For continuous integration on meteor core, and smart packages, Naomi Seyfer and I are chatting with the founder of circleci to see if we can get something awesome implemented in the near term.

---

RTD has now been deprecated and replaced by Velocity, which is the official testing framework for Meteor 1.0. Documentation is still relatively new as Velocity is under heavy development. You can find some more information on the Velocity Github repo, the Velocity Homepage and The Meteor Testing Manual (paid content)

Disclaimer: I'm one of the core team members of Velocity and the author of the book.

---

Check out RTD, a full testing framework for Meteor here rtd.xolv.io. It supports Jasmine/Mocha/custom and works with both plain JS and coffee. It includes test coverage too that combines unit/server/client coverage.

And an example project here

A blog to explain unit testing with Meteor here

An e2e acceptance testing approach using Selenium WebdriverJS and Meteor here

Hope that helps. Disclaimer: I am the author of RTD.

---

I used this page a lot and tried all of the answers, but from my beginner's starting point, I found them quite confusing. Once I had any trouble, I was flummoxed as to how to fix them.

This solution is really simple to get started with, if not fully documented yet, so I recommend it for people like myself who want to do TDD but aren't sure how testing in JavaScript works and which libraries plug into what:

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

FYI, I found that I also need to use the router Atmosphere package to make a '/tests' route to run and display the results from the tests, as I didn't want it to clutter my app every time it loads.

---

About the usage of tinytest, you may want to take a look at those useful ressources:

1. The basics are explained in this screencast: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. Once you understood the idea, you'll want the public API documentation for tinytest. For now, the only documentation for that is at the end of the source of the tinytest package: https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Also, the screencast talks about test-helpers, you may want to have a look at all the available helpers in here: https://github.com/meteor/meteor/tree/devel/packages/test-helpers There often is some documentation inside each file

4. Digging in the existing tests of meteor's packages will provide a lot of examples. One way of doing this is to make a search for Tinytest. or test. in the package directory of meteor's source code

---

Testing becomes a core part of Meteor in the upcoming 1.3 release. The initial solution is based on Mocha and Chai.

The original discussions of the minimum viable design can be found here and the details of the first implementation can be found here.

MDG have produced the initial bones of the guide documentation for the testing which can be found here, and there are some example tests here.

This is an example of a publication test from the link above:

  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();
    });
  });

---

I'm doing functional/integration tests with Meteor + Mocha in the browser. I have something along the lines of the following (in coffeescript for better readability):

On the client...

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="/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()

...and on the server:

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

Of course you can do your client-side unit testing in the same way. For integration testing it's nice to have all Meteor infrastructure around, though.

---

As Blackcout said, Velocity is the official TDD framework for Meteor. But at this moment velocity's webpage doesn't offer good documentation. So I recommend you to watch:

• Concept behind velocity
• Step by step tutorial
• And specially the Official examples

---

Another option, made easily available since 0.6.0, is to run your entire app out of local smart packages, with a bare minimum amount of code outside of packages to boot your app (possibly invoking a particular smart package that is the foundation of your app).

You can then leverage Meteor's Tinytest, which is great for testing Meteor apps.

---

Ive successfully been using xolvio:cucumber and velocity to do my testing. Works really well and runs continuously so you can always see that your tests are passing.

---

Meteor + TheIntern

Somehow I managed to test Meteor application with TheIntern.js.

Though it is as per my need. But still I think it may lead someone to the right direction and I am sharing what I have done to resolve this issue.

There is a execute function which allows us to run JS code thorugh which we can access browsers window object and hence Meteor also.

Want to know more about execute

This is how my test suite looks for Functional Testing

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');
                });
        }
    });
});

To know more, this is my gist

Note: I am still in very early phase with this solution. I don't know whether I can do complex testing with this or not. But i am pretty much confident about it.

---

Velocity is not mature yet. I am facing setTimeout issues to use velocity. For server side unit testing you can use this package.

It is faster than velocity. Velocity requires a huge time when I test any spec with a login. With Jasmine code we can test any server side method and publication.

참고URL : https://stackoverflow.com/questions/12987525/meteor-test-driven-development