2015-04-20 12 views
10

Secondo the blog-post per ember-data versione 1.0.0-beta.16 il negozio può ora essere utilizzato come un servizio:Come posso dipendere dal negozio come servizio nei test delle unità Ember usando qunit?

TweetComposerComponent = Ember.Component.extend({ 
    store: Ember.inject.service()  
}); 

Tuttavia, non riesco a capire come fare qunit unit test su tale componente. Ho provato la seguente:

moduleForComponent('tweet-composer', { 
    needs: ['service:store'] 
}); 

e:

moduleForComponent('tweet-composer', { 
    needs: ['store:main'] 
}); 

E quando faccio l'ex ottengo un errore Attempting to register an unknown factory: 'service:store' e se lo faccio quest'ultimo poi store è undefined.

Pensieri?

(Sto scrivendo un'app stile ember-cli).

Aggiornamento:

sembra che ci sia un open issue per questo nel repository brace-test-aiutanti.

Mentre sto aspettando questa correzione, ho cucinato un aiutante che può funzionare come una misura tappabuchi (CoffeeScript):

`import TestModuleForComponent from 'ember-test-helpers/test-module-for-component'` 
`import { createModule } from 'ember-qunit/qunit-module'` 

# This assumes the last argument, the callbacks, is present, although it 
# does support the description being an optional argument. 
moduleForStoreComponent = -> 
    args = Array.prototype.slice.call arguments 
    callbacks = args[args.length-1] 
    # Wrap the original beforeEach callback in a modified version that 
    # also sets up the store for the test container. 
    originalSetup = callbacks.beforeEach 
    callbacks.beforeEach = -> 
    DS._setupContainer(@container) 
    originalSetup.call(@) if originalSetup 
    callbacks.store = -> 
    @container.lookup('store:main') 
    args.unshift TestModuleForComponent 
    createModule.apply @, args 

`export default moduleForStoreComponent` 

risposta

12

uno unit test è un luogo dove tutto funziona perfettamente tranne la codice/componente/unità che stai testando.

Quindi, anche il store deve essere considerato funzionante perfettamente (0 errori/bug).

Qualcosa del genere dovrebbe funzionare nel test:

moduleForComponent('tweet-composer', { 
    beforeEach: function() { 
     this.subject({ 
      store: {/*empty object*/} 
     }); 
    } 
}); 

Se parti dei test dipendono da dati recuperati dal negozio, si può fare qualcosa di simile:

this.subject({ 
    store: { 
     find: function() { 
      var mockedModel = Ember.Object.create({/*empty*/}); 
      return mockedModel; 
     } 
    } 
}); 

Questo è quello di preservare lo stato di "unit test", se inizi a includere e registrare altri oggetti dalla tua app, starai effettivamente scrivendo test di integrazione.

Nota:

In generale, guardando modelli direttamente in un componente è un anti-modello , e si dovrebbe preferire di passare in qualsiasi modello che avete bisogno nel il modello che ha incluso il componente.

http://discuss.emberjs.com/t/should-ember-components-load-data/4218/2?u=givanse

+0

test di collaudo estremamente lento. Preferisco usarli solo se sto testando molti aspetti dell'applicazione. Se sto provando esattamente due pezzi, ha molto più senso solo istanziare quei due pezzi e testarli insieme, ma separatamente dal resto dell'app. –

+1

Sono consapevole del thread che hai citato e apprezzo il consiglio, ma sono nel campo che ritiene che ci siano alcuni usi limitati e appropriati per consentire l'accesso al negozio all'interno di determinati componenti.In particolare, quando lo stato rappresentato nel componente non è derivato dall'URL, ma piuttosto un aspetto intrinseco e isolato del componente, può avere senso isolare questo stato nel componente e non inquinare tutti i percorsi che presentano il componente con la logica richiesta per istanziare i modelli e aggiornarli come stato interno alle modifiche del componente. –

+0

D'accordo, hai un buon punto lì. Anche allora, in questo tipo di test (il tuo componente), ciò che stai testando è la logica del componente e non il negozio. Quindi non importa da dove provengano i dati. Ciò che il test deve fare è verificare che parti di dati diverse attivino gli eventi corretti e producano risultati attesi. – givanse