Rozwój oparty na testach meteorologicznych [zamknięty]

Nie rozumiem, jak w meteorze zrobić programowanie sterowane testami.

Nie widzę tego w dokumentacji ani w FAQ. Nie widzę żadnych przykładów ani czegoś takiego.

Widzę, że niektóre pakiety używają Tinytest.

Potrzebowałbym odpowiedzi od programistów, jaki jest plan dotyczący tego. Coś w rodzaju:

• możliwe, brak dokumentacji, zrób to sam
• meteor nie jest zbudowany w sposób umożliwiający tworzenie testowalnych aplikacji
• jest to planowana funkcja
• itp

Aktualizacja 3 : Od wersji Meteor 1.3 meteor zawiera przewodnik po testach z instrukcjami krok po kroku dotyczącymi testów jednostkowych, integracji, akceptacji i obciążenia.

Aktualizacja 2 : Od 9 listopada 2015 r. Velocity nie jest już obsługiwane . Xolv.io koncentruje swoje wysiłki na szympansie , a Meteor Development Group musi wybrać oficjalną platformę testową .

Aktualizacja : Velocity jest oficjalnym rozwiązaniem testowym firmy Meteor od 0.8.1.

W tej chwili niewiele napisano o automatycznych testach z Meteor. Oczekuję, że społeczność Meteor rozwinie sprawdzone metody testowania, zanim cokolwiek znajdzie się w oficjalnej dokumentacji. W końcu Meteor osiągnął w tym tygodniu 0,5, a sytuacja nadal szybko się zmienia.

Dobra wiadomość: możesz używać narzędzi testowych Node.js z Meteor .

W moim projekcie Meteor przeprowadzam testy jednostkowe z Mocha, używając Chai do asercji. Jeśli nie potrzebujesz pełnego zestawu funkcji Chai, polecam zamiast tego użycie should.js . W tej chwili mam tylko testy jednostkowe, chociaż możesz również pisać testy integracyjne z Mocha.

Pamiętaj, aby umieścić testy w folderze "testy" , aby Meteor nie próbował ich wykonywać.

Mocha obsługuje CoffeeScript , mój wybór języka skryptowego dla projektów Meteor. Oto przykładowy plik Cakefile z zadaniami do uruchamiania testów Mocha. Jeśli używasz JS z Meteor, możesz swobodnie dostosować polecenia do pliku Makefile.

Twoje modele Meteor będą wymagały niewielkiej modyfikacji, aby wystawić się na działanie Mocha, a to wymaga pewnej wiedzy na temat działania Node.js. Pomyśl o każdym pliku Node.js jako wykonywanym w jego własnym zakresie. Meteor automatycznie eksponuje obiekty w różnych plikach, ale zwykłe aplikacje Node - takie jak Mocha - tego nie robią. Aby nasze modele były testowalne przez Mocha, wyeksportuj każdy model Meteor z następującym wzorem 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?

... a na początku testu Mocha zaimportuj model, który chcesz przetestować:

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

Dzięki temu możesz zacząć pisać i uruchamiać testy jednostkowe w swoim projekcie Meteor!

Witam wszystkich, checkout laika - cała nowa platforma testowa dla meteor http://arunoda.github.io/laika/

Możesz jednocześnie przetestować serwer i klienta.

• Zobacz przykład laika tutaj
• Zobacz tutaj funkcje
• Zobacz koncepcję laika
• Zobacz repozytorium Github

Zastrzeżenie: jestem autorem Laika.

Zdaję sobie sprawę, że odpowiedź na to pytanie została już udzielona, ​​ale myślę, że przydałoby się trochę więcej kontekstu, w postaci dodatkowej odpowiedzi, podającej wspomniany kontekst.

Zajmowałem się rozwojem aplikacji w meteor, a także pakietami, zarówno poprzez implementację pakietu dla rdzenia meteorowego, jak i dla atmosfery .

Wygląda na to, że Twoje pytanie może składać się z trzech części:

1. Jak przeprowadzić cały zestaw testów meteorowych?
2. Jak napisać i uruchomić testy dla poszczególnych inteligentnych pakietów ?
3. Jak napisać i uruchomić testy dla własnej aplikacji?

Wygląda też na to, że gdzieś tam może być dodatkowe pytanie: 4. Jak można wdrożyć ciągłą integrację dla 1, 2 i 3?

Rozmawiałem i zacząłem współpracować z Naomi Seyfer (@sixolet) w głównym zespole firmy Meteor , aby uzyskać ostateczne odpowiedzi na wszystkie te pytania w dokumentacji.

Przesłałem wstępne żądanie ściągnięcia adresujące 1 i 2 do rdzenia meteor: https://github.com/meteor/meteor/pull/573 .

Niedawno odpowiedziałem też na to pytanie: Jak przeprowadzasz testy meteorytów?

Myślę, że @Blackcoat ostatecznie odpowiedział 3 powyżej.

Jeśli chodzi o bonus, 4, sugerowałbym użycie cirleci.com przynajmniej do ciągłej integracji z własnymi aplikacjami. Obecnie obsługują przypadek użycia opisany przez @Blackcoat. Mam projekt, w którym pomyślnie przeszedłem testy napisane w skrypcie coffeescript, aby uruchomić testy jednostkowe z mokką, prawie tak, jak opisał @Blackcoat.

Aby zapewnić ciągłą integrację z rdzeniem meteorytu i inteligentnymi pakietami, rozmawiamy z Naomi Seyfer z założycielką circleci, aby sprawdzić, czy w najbliższym czasie uda nam się wdrożyć coś niesamowitego.

RTD jest obecnie przestarzałe i zastąpione przez Velocity, oficjalną platformę testową dla Meteor 1.0. Dokumentacja jest wciąż stosunkowo nowa, ponieważ Velocity jest w trakcie intensywnego rozwoju. Więcej informacji można znaleźć w repozytorium Velocity Github , stronie internetowej Velocity i podręczniku testowania Meteor (treści płatne)

Zastrzeżenie: Jestem jednym z głównych członków zespołu Velocity i autorem książki.

Sprawdź RTD, pełne ramy dla badań Meteor tutaj rtd.xolv.io . Obsługuje Jasmine / Mocha / custom i działa zarówno ze zwykłym JS, jak i kawą. Obejmuje również pokrycie testowe, które łączy pokrycie jednostki / serwera / klienta.

Przykładowy projekt tutaj

Blog wyjaśniający testy jednostkowe z Meteor tutaj

Podejście do testów akceptacyjnych e2e przy użyciu Selenium WebdriverJS i Meteor tutaj

Mam nadzieję, że to pomoże. Zastrzeżenie: jestem autorem RTD.

Często korzystałem z tej strony i wypróbowałem wszystkie odpowiedzi, ale od punktu wyjścia dla mojego początkującego uznałem je za dość zagmatwane. Kiedy miałem jakiekolwiek problemy, byłem zbity z tropu, jak je naprawić.

To rozwiązanie jest naprawdę łatwe do rozpoczęcia, jeśli nie jest jeszcze w pełni udokumentowane, więc polecam je osobom takim jak ja, którzy chcą robić TDD, ale nie są pewni, jak działa testowanie w JavaScript i które biblioteki podłączają do czego:

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

Do Twojej wiadomości, stwierdziłem, że muszę również użyć pakietu Atmosphere routera, aby utworzyć trasę `` / tests '', aby uruchomić i wyświetlić wyniki testów, ponieważ nie chciałem, aby za każdym razem ładował moją aplikację.

Jeśli chodzi o korzystanie z Tinytest, możesz rzucić okiem na te przydatne zasoby:

1. Podstawy są wyjaśnione w tym screencast: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. Gdy zrozumiesz pomysł, będziesz potrzebować publicznej dokumentacji API dla tinytest. Na razie jedyna dokumentacja na ten temat znajduje się na końcu źródła tinytestpakietu: https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Ponadto, screencast mówi o tym test-helpers, że możesz chcieć rzucić okiem na wszystkich dostępnych pomocników tutaj: https://github.com/meteor/meteor/tree/devel/packages/test-helpers Często w każdym z nich znajduje się dokumentacja plik

4. Przeglądanie istniejących testów opakowań firmy Meteor dostarczy wielu przykładów. Jednym ze sposobów jest wyszukanie Tinytest.lub test.w katalogu pakietów kodu źródłowego meteor

Testowanie stanie się podstawową częścią Meteor w nadchodzącej wersji 1.3. Wstępne rozwiązanie bazuje na Mocha i Chai.

Oryginalne dyskusje na temat minimalnego opłacalnego projektu można znaleźć tutaj, a szczegóły dotyczące pierwszej implementacji można znaleźć tutaj .

MDG opracowało początkowe fragmenty dokumentacji przewodnika do testów, którą można znaleźć tutaj , a tutaj jest kilka przykładowych testów .

Oto przykład testu publikacji z linku powyżej:

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

Robię funkcjonalnej integracji / testy z Meteor + Mocha w przeglądarce. Mam coś podobnego do następującego (w skrypcie kawowym dla lepszej czytelności):

Na kliencie ...

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

... a na serwerze:

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

Oczywiście w ten sam sposób możesz przeprowadzić testy jednostkowe po stronie klienta . Jednak do testów integracyjnych dobrze jest mieć całą infrastrukturę Meteor w pobliżu.

Jak powiedział Blackcout, Velocity to oficjalny framework TDD dla Meteor. Ale w tej chwili strona internetowa velocity nie oferuje dobrej dokumentacji. Polecam więc obejrzeć:

• Pojęcie prędkości
• Samouczek krok po kroku
• A zwłaszcza oficjalne przykłady

Inną opcją, łatwo dostępną od wersji 0.6.0, jest uruchomienie całej aplikacji z lokalnych inteligentnych pakietów, z minimalną ilością kodu poza pakietami, aby uruchomić aplikację (prawdopodobnie wywołując konkretny inteligentny pakiet, który jest podstawą twojego app).

Następnie możesz wykorzystać Tinytest firmy Meteor, który doskonale nadaje się do testowania aplikacji Meteor.

Z powodzeniem używam xolvio: cucumber and velocity do moich testów. Działa naprawdę dobrze i działa w sposób ciągły, więc zawsze możesz zobaczyć, że testy kończą się pomyślnie.

Meteor + TheIntern

Jakoś udało mi się przetestować aplikację Meteor z TheIntern.js.

Chociaż jest to na moją potrzebę. Ale nadal myślę, że może to kogoś poprowadzić we właściwym kierunku i dzielę się tym, co zrobiłem, aby rozwiązać ten problem.

Jest executefunkcja, która pozwala nam uruchomić kod JS, poprzez który możemy uzyskać dostęp do windowobiektu przeglądarki, a tym samym Meteorrównież.

Chcesz dowiedzieć się więcej o wykonywaniu

Tak test suitewygląda moje podejście do testów funkcjonalnych

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

Aby dowiedzieć się więcej, to jest moje sedno

Uwaga: nadal jestem na bardzo wczesnym etapie z tym rozwiązaniem. Nie wiem, czy mogę z tym przeprowadzić złożone testy, czy nie. Ale jestem tego całkiem pewny.

Prędkość nie jest jeszcze dojrzała. Mam problemy z setTimeout, aby używać prędkości. Do testów jednostkowych po stronie serwera możesz użyć tego pakietu .

Jest szybsza niż prędkość. Velocity wymaga ogromnego czasu, kiedy testuję dowolną specyfikację przy logowaniu. Za pomocą kodu Jasmine możemy przetestować dowolną metodę i publikację po stronie serwera.