2011-11-04 5 views
15

Ho scritto un metodo di classe semplice Buy.get_days(string) e sto provando a verificarlo con input di stringa di testo diversi. Tuttavia ritengo che sia molto prolisso.Come testare i metodi di classe in RSPEC

  • Esiste un modo più conciso per verificare quanto segue?
  • Esiste un equivalente di subject per metodi cui posso solo continuare passando diversi parametri e controllare i risultati?
  • C'è un modo per evitare la descrizione non necessaria in ogni it?

grazie

describe Buy do 
    describe '.get_days' do 
    it 'should get days' do 
     Buy.get_days('Includes a 1-weeknight stay for up to 4 people') 
     .should == 1 
     end 
    it 'should get days' do 
     Buy.get_days('Includes a 1-night stay in a King Studio Room with stone fireplace') 
     .should == 1 
    end 
    it 'should get days' do 
     Buy.get_days('Includes 4 nights/5 days at the Finisterra Hotel for up to two adults and two children (staying in the same room)') 
     .should == 4 
    end 
    end 
end 
+4

Come è inutile la descrizione 'it'? Solo perché hai scritto lo stesso testo per le specifiche che testano cose diverse non significa che la descrizione non dovrebbe essere lì - magari ridiscutali in modo che siano utili? –

+0

la combinazione di input/output è sufficientemente descrittiva (almeno per me). – lulalala

+0

puoi dare un esempio di riformulazione per renderlo più utile, @DaveNewton? – ahnbizcad

risposta

3

This è un modo interessante, anche se forse più ottuso, di utilizzare il blocco "oggetto" con i metodi Class.

Modifica: lo link danneggiato come riportato dal Wayback Archive che suppongo sia suscettibile allo stesso problema.

+1

[collegamento interrotto] (http://posterous.timocracy.com/a-pattern-for-testing-class-methods-in-ruby-w) dice "Gli spazi Poster non sono più disponibili" –

+0

@JaredBeck modificato. Riassumo la risposta stasera. – TCopple

+0

Il contenuto è anche disponibile come sintesi: https://gist.github.com/timocratic/816049 – aingram

11

Non c'è una subject equivalente per chiamare un metodo, in modo da utilizzare it è il modo di andare qui. Il problema che vedo con il tuo codice come presentato è che in realtà non spiega cosa stai provando per. Vorrei scrivere qualcosa di più simile:

describe Buy do 
    describe '.get_days' do 
    it 'should detect hyphenated weeknights' do 
     Buy.get_days('Includes a 1-weeknight stay for up to 4 people').should == 1 
    end 
    it 'should detect hyphenated nights' do 
     Buy.get_days('Includes a 1-night stay in a King Studio Room with stone fireplace').should == 1 
    end 
    it 'should detect first number' do 
     Buy.get_days('Includes 4 nights/5 days at the Finisterra Hotel for up to two adults and two children (staying in the same room)').should == 4 
    end 
    end 
end 

Sto facendo ipotesi su quello che stai dopo qui, ma si spera che l'idea è chiara. Ciò porterà anche a un output di errore molto più utile quando un test fallisce. Spero che questo ti aiuti!

+0

Suppongo che la risposta alla fine sia: non esiste un modo più conciso di scriverlo. – lulalala

+0

Sì, ho paura. :) –

+0

@lulalala Non vuoi * che sia conciso, vuoi che sia accurato e descrittivo nel contesto delle specifiche. –

0

Un'alternativa all'utilizzo subject/it è quello di utilizzare before/specify:

describe '#destroy' do 
    context 'with children' do 
    before { @parent = FactoryGirl.create(:parent, children: FactoryGirl.create_list(:child, 2) } 
    specify { @parent.destroy.should be_false } 
    end 
end 

questo produrrà una descrizione ragionevole in formato -fd uscita del RSpec:

#destroy 
    with children 
    should be false 
5

Questa potrebbe essere una vecchia questione ma puoi sempre usare subject.class per ottenere:

describe Buy do 
    describe '.get_days' do 
    it { expect(subject.class.get_days('Includes a 1-weeknight stay for up to 4 people')).to eq 1 } 
    end 
end 
+0

Buona cattura ! facepalm. Avrei dovuto saperlo. Questa è la risposta corretta! – ahnbizcad

+1

'subject.class'? Non sarebbe più chiaro usare 'Acquista'? –

+0

@ahnbizcad Non proprio, perché mostra solo un singolo test. Pensa all'output spec e a cosa dovrebbe essere mostrato. L'aggiunta degli altri test senza test descrittivi rende sostanzialmente inutile l'output delle specifiche perché non si conosce (a) ciò che la specifica sta testando e (b) ciò che differenzia le diverse specifiche. –

7

Apparentemente esiste un metodo described_class.

https://www.relishapp.com/rspec/rspec-core/docs/metadata/described-class

suppongo che sia più pulita di subject.class, in quanto non introduce un'altra chiamata . metodo, che riduce la leggibilità.

L'utilizzo di described_class o subject.class può essere più ASCIUTTO che menzionare esplicitamente la classe in ogni esempio. Ma personalmente ritengo che non sia l'evidenziazione della sintassi che viene menzionata esplicitamente nel nome della classe è una specie di fiasco, e penso che riduca la leggibilità, nonostante sia totalmente vincente nel reparto di manutenibilità.

Una domanda si pone per quanto riguarda le migliori pratiche:

si dovrebbe utilizzare described_class quando possibile dentro e fuori il metodo .expect(), oppure solo all'interno del metodo expect()?

+0

Questo è quello che preferisco usare nei miei test, lasciando il soggetto per i dati testati attraverso questi metodi. – DBrown