La risposta breve è “no, non mi trovo bene ma sono costretto dalle
circostanze”.
Quella più articolata, scritta a più riprese mentre girano i test, è che
l’applicazione era totalmente scoperta perché i test esistenti sono
stati rotti dall’ultimo aggiornamento prima del mio arrivo e gli
sviluppatori per qualche buona ragione (gli do credito) non avevano
avuto tempo per sistemarli. All’inizio avevo dovuto lavorare in
emergenza anch’io ma adesso è imperativo avere un test. Formalmente ci
mette dai 4 ai 5 minuti a girare, ma tra i tempi di startup…
(ecco mi ha detto ora “Finished in 4 minutes 1.81 seconds”, adesso
misuro il tempo reale col cronometro del telefono)
… e alle volte quelli di shutdown
Rspec sometimes takes forever to finish on failed spec example(s) · Issue #601 · rspec/rspec-core · GitHub ci vuole un po’ di più ed
il debug dei test è lento.
Ma ci sono anche dei vantaggi, tipo fare qualche esercizio su duolingo
mentre attendo 
Più spesso però vado avanti a scrivere altri pezzi di
test mentre gira quello attuale. Adesso ho quasi finito e dopo il
rilascio in produzione dovrò scrivere anche qualche test più mirato su
modelli e controller per provare in fretta la correttezza delle
modifiche che faccio.
(“Finished in 4 minutes 37.23 seconds” contro 5 minuti e 16 secondi
reali - sorprendente quanto tempo ci voglia a scrivere un paragrafo se
nel frattempo devi googlare cose… ora sistemo un po’ di cose e poi
riprendo la risposta)
Come db sto usando mysql e per inciso sono incappato in
passando alla gemma mysql2
Non ho idea se funzionerebbe anche con sqllite. Eventualmente c’è
qualche versione in RAM di mysql? Mi verrebbe utile pure sul netbook
quando alle volte lo uso per programmare in giro.
(“Finished in 4 minutes 37.45 seconds” vs 5.18, l’overhead pare
costante)
Ho googlato un po’ ed ho scoperto che MySQL ha l’engine MEMORY. In
teoria basta mettere questo codice in un initializer, ma in pratica le
tabelle mi vengono ancora create con InnoDB.
Based on AR 3.0.15 and
http://blog.teksol.info/2008/12/12/mysqls-memory-engine-barely-faster-than-innodbs
module ActiveRecord
module ConnectionAdapters
class MysqlAdapter < AbstractAdapter
def create_table(table_name, options = {}) #:nodoc:
engine = case Rails.env
when “test”
“MEMORY”
else
“InnoDB”
end
super(table_name, options.reverse_merge(:options =>
“ENGINE=#{engine}”))
end
end
end
end
L’autore si lamentava che il suo test era passato da 1.8 s a 1.1 s, che
per lui era irrilevante, ma nel mio caso guadagnarei almeno un minuto.
Indagherò, e farò anche la prova con sqlite.
Paolo
Sergio B. wrote in post #1068358:
Il giorno 09 luglio 2012 22:13, Paolo M.
[email protected]ha scritto:
E’ circa quello che sto facendo ma non l’ideale avere un solo blocco
it che gira per minuti senza feedback di avanzamento n feedback su dove
capitano degli errori. Va detto che essendo una sequenza unica, il primo
errore blocca sempre tutto quello che segue quindi forse la separazione
in blocchi irrilevante.
C’ nessuno che si trovato a scrivere test di questo genere? Che
approccio avete seguito?
Paolo ma a parte rspec-steps ti trovi bene con un test di integrazione
che
dura (tanti) minuti ?
Ok che di integrazione, quindi lento per definizione.
Ok che deve usare tutto, db compreso (ed usare mock al posto del db
reale
lo rende meno utile).
Ma non riesci a velocizzarlo usando che so, un db locale in process
invece
del db server reale ?
Tipo se usi oracle per il test usare sqlite
Ciao,
Sergio