Test delle rotaie: infissi, fabbriche e numeri magici

Question

Ho un'applicazione che ha bisogno di un bel po 'di dati (migliaia di record) per eseguire test appropriati. L'unico modo che ho trovato per ottenere un set decente di dati testabili e sensibili è utilizzare un sottoinsieme del mio DB di produzione . Ho convertito questo in apparecchi YAML nella normale posizione "test / infissi".

Funziona, ma ora ho un sacco di test e asserzioni apparentemente fragili che dipendono dal loro essere un numero particolare di record che soddisfano la condizione X ...

Esempio

def test_children_association
  p = Parent.find(1)
  assert_equal 18, p.children.count, "Parent.children isn't providing the right records"
end

Non mi sembra una buona idea, ma non sono sicuro che esista un modo migliore / accettato per testare un'applicazione che necessita di una grande gerarchia di dati.

Answer 1

I numeri magici nei test non sono un anti-schema. I test devono essere così semplicissimi che non è necessario testarli . Ciò significa che avrai alcuni numeri magici. Ciò significa che i test si interromperanno quando si modificano piccoli bit di funzionalità. Questo va bene.

Le partite hanno alcuni problemi , ma ci sono alcune semplici cose che puoi fare per renderle più facili da lavorare:

1. Nei tuoi infissi sono presenti solo dati di base, il tipo di dati di cui la maggior parte dei tuoi test ha bisogno ma che non ti interessano. Ciò comporterà un investimento di tempo in anticipo, ma è meglio affrontare il dolore piuttosto che scrivere test unitari scadenti per la durata del progetto.

2. Aggiungi i dati da testare nel contesto del test. Ciò migliora la leggibilità dei tuoi test e ti evita di scrivere "assicurati che nessuno abbia incasinato i dispositivi". controlli di integrità all'inizio dei test unitari.

Answer 2

La prima cosa che direi è: cosa stai testando in questo esempio? Se è un'associazione AR has_many ordinaria, non mi preoccuperei di scrivere un test per questo. Tutto quello che stai facendo è testare il funzionamento dell'AR.

Un esempio migliore potrebbe essere se si fosse verificata una query molto complicata o se fosse stata coinvolta un'altra elaborazione per ottenere l'elenco dei record figlio. Quando li recuperi, anziché eseguire il test per un conteggio, puoi scorrere l'elenco restituito e verificare che i bambini soddisfino i criteri che stai utilizzando.

Answer 3

ciò che ho trovato più utile in questa situazione non è affatto l'utilizzo di dispositivi, ma piuttosto costruire gli oggetti del database al volo come

def test_foo
   project = Project.create valid_project.merge(....)
   *do assertions here*
end

e nei miei test_helper avrei un sacco di metodi:

def valid_project
   { :user_id => 23, :title => "My Project" }
end

def invalid_project
   valid_project.merge(:title => nil)
end

Ho scoperto che il dolore di dover costruire enormi raccolte di oggetti di prova mi ha portato naturalmente a progettare strutture di classe più semplici e versatili.

Answer 4

Cameron ha ragione: cosa stai testando?

Che tipo di sistema necessita di migliaia di record presenti per testare? Ricorda, i tuoi test dovrebbero essere il più piccoli possibile e dovrebbero testare il comportamento delle applicazioni. Non c'è modo di aver bisogno di migliaia di record per la stragrande maggioranza di questi test.

Per piccoli pezzetti di test comportamentali in cui sono necessarie relazioni tra oggetti, considerare gli oggetti simulati. Specificherai solo l'esatta quantità minima di comportamento necessaria per far passare il test e non colpiranno affatto il DB, il che comporterà un enorme aumento delle prestazioni nella tua suite di test. Più veloce sarà, più spesso le persone lo eseguiranno.

Answer 5

Potrei avere una situazione unica qui, ma ho davvero avuto bisogno di un bel po 'di record per testare questa app (sono arrivato a 150 o giù di lì). Sto analizzando i dati storici e ho numerosi livelli di has_many . Alcuni dei miei metodi eseguono query SQL personalizzate su più tabelle che potrei finire modificando per utilizzare ActiveRecord.find ma prima dovevo eseguire il test

Comunque, ho finito per usare un po 'di codice ruby ??per creare le partite . Il codice è incluso nel mio test_helper ; controlla il DB di prova per vedere se i dati sono obsoleti (in base a una condizione temporale) e cancella e ricrea i registri in modo procedurale . In questo caso, crearlo proceduralmente mi permette di sapere quali sono i dati che sto testando per DOVREBBE , che è più sicuro dell'uso di un sottoinsieme di dati di produzione e sperando che i numeri Calcolo la prima volta sono ciò che dovrei testare in futuro.

Ho anche iniziato a utilizzare Shoulda che insieme a molte altre cose utili rende l'Associazione ActiveRecord test facile come:

should_have_many :children
should_belong_to :parent