2015-03-18 14 views
6

ho 'allenamenti' una collezione come segue:Come testare un metodo di meteora personalizzato con Velocity + Jasmine

Workouts = new Mongo.Collection('workouts'); 

Meteor.methods({ 
    workoutInsert: function() { 
    var user = Meteor.user(); 

    check(user._id, String); 

    var workout = { 
     completed: false, 
     createdAt: new Date(), 
     userId: user._id 
    }; 

    var workoutId = Workouts.insert(workout); 

    return { 
     _id: workoutId 
    }; 
    } 
}); 

Mi chiedo:

1) Cosa sarebbe un aspetto di test di velocità + Jasmine come per questo metodo? Non sono sicuro da dove cominciare e mi piacerebbe davvero apprezzare ed esempio!

2) È la procedura migliore per definire questo metodo e chiamarlo lato client? O forse dovrei creare una classe di allenamento e aggiungere la chiamata a questo metodo da un metodo di istanza di quella classe? O dovrei forse estendere gli allenamenti per essere la sua classe e aggiungere metodi di istanza a questo?

risposta

3

In Meteor sono disponibili diversi tipi di test: integrazione client, unità client, integrazione server e unità server.

I test di integrazione rispecchiano il tuo sito e caricano i tuoi metodi Meteor per te (ad esempio workoutInsert).

Se fossi prove, potrei avere qualcosa come:

//File Location: app/tests/server/integration/workoutsSpec.js 
Jasmine.onTest(function() { 
    describe('workouts', function() { 
     it("should call to Workouts.insert",function(){ 

     //Make user return truthy _id for testing 
     Meteor.user() = function(){return {_id : "1";}} 

     //Setup a spy to watch for calls to Workouts.insert 
     spyOn("Workouts",insert); 

     //Call workoutInsert Meteor Method 
     Meteor.call('workoutInsert'); 

     //Verify if Workouts.insert was called 
     expect("Workouts.insert").toHaveBeenCalled(); 
     }); 
    }); 
}); 

Infine, MeteorJS ti dà un sacco di libertà di come si sceglie di implementare le cose e non c'è modo chiaro migliore per fare le cose che funziona per ogni scenario. Tuttavia, consiglierei di non inserire alcun codice che interagisca con il tuo database sul tuo client. Qualcosa che si trova nel tuo client folder is publicly accessible/readable per i tuoi utenti (hanno bisogno di vedere i dettagli di convalida di basso livello?).

0

Per rispondere alla seconda domanda, è consigliabile mantenere i metodi Meteor isolati nella directory del server. Meteor usa questi nomi di directory riservati per darti il ​​controllo sulle risorse che sono servite al client, al server o ad entrambi. Non è necessario averli nello stesso file o directory delle raccolte Mongo, poiché tutte le raccolte possono essere disponibili sia sul client che sul server. Questa è generalmente considerata la migliore pratica, specialmente se si utilizzano framework come angular-meteor che si basano sulle definizioni di raccolta disponibili sul client, in modo che i filtri possano essere passati a loro. È possibile proteggere e modificare le autorizzazioni per queste collezioni sul usando collection.allow()/deny()

Quindi, se mantenuto tutte le vostre collezioni nella directory collections/ potrebbero essere definiti in questo modo:

Workouts = new Mongo.Collection('workouts'); 

sarebbe il contenuto del collections/workouts.js

Quindi, nella tua directory server/, allo stesso livello del tuo collections/, puoi mettere tutti i tuoi metodi in un file a questo livello o più in profondità nell'albero, come una directory server/methods/. Quindi puoi inserire i tuoi metodi in un workouts.js in questa directory, se lo desideri.

Meteor.methods({ 
    workoutInsert: function() { 
    var user = Meteor.user(); 

    check(user._id, String); 

    var workout = { 
     completed: false, 
     createdAt: new Date(), 
     userId: user._id 
    }; 

    var workoutId = Workouts.insert(workout); 

    return { 
     _id: workoutId 
    }; 
    } 
}); 
+0

"la pratica migliore è mantenere i metodi Meteor isolati nella directory del server" ma per quanto riguarda i metodi stub e la compensazione della latenza? –

+0

@Kyll Non ho avuto ancora problemi con la latenza con Meteor. Se si dispone di una gestione degli abbonamenti vigente sul lato client (ad esempio l'interruzione delle sottoscrizioni per i modelli fuori vista e simili), è possibile mantenere la latenza anche con raccolte massicce. Gli stub di metodi sono qualcosa a cui mi sto ancora abituando, ma il framework di test ufficiale di Meteor Velocity fa un lavoro decente nel gestire i tuoi stub per te e finora ho avuto una buona esperienza con esso. –

+0

Quello che intendevo è che isolando i metodi sul lato server si perde la capacità del client di anticipare le modifiche e di aggiornare l'interfaccia utente in modo ottimistico. –