Controllo record nel database durante i test di integrazione

Community IT
1

Quanti di voi, durante gli integration test, eseguono delle verifiche
nel
database per verificare delle expectations?

Io lo sto facendo con capybara, per controllare che i background jobs
facciano il loro dovere.
Ma la cosa non proprio gradevole, mi trovo a mettere degli sleep in
giro
(degli sleep, non slip :D).

So che bisognerebbe testare solo l’interfaccia, ma controllare anche i
record nel mio caso ha un gran valore.

Che dite?

2

Che gemma usi per i background jobs?

Ju

–
M.Sc. Ju Liu
Twitter: @arkh4m http://twitter.com/arkh4m
Skype: johnny_arkham
Card: http://zerp.ly/ju-liu

Societ Cooperativa weLaika
Corso Vigevano 14/B, 10154 Torino (TO), Italy
http://welaika.com - [email protected]

2014-10-02 12:09 GMT+01:00 Fabrizio R. [email protected]:

3

Sidekiq in testing mode. Il processing the jobs quindi sincrono nel
test,
il problema che secondo me passa del tempo tra l’evento che si svolge
in
capybara e quello che io posso raccogliere durante l’esecuzione del test
visto che i thread sono diversi.

Esempio:

  1. creo un record ‘site’ nel database usando factory_girl
  2. carico una pagna relativa al record ‘site’
  3. un javascript alquanto complesso viene eseguito
  4. pollo la pagina con eval_javascript per vedere se un determinato
    elemento presente nella pagina
  5. quando quell’elemento visibile mi aspetto che sia partita una
    chiamata
    ajax per registrare un evento server side
  6. l’evento server side registra un record con sidekiq
  7. faccio la query per vedere se l’evento stato registrato nel db

Ho un dubbio anche che il punto 0 sia consistente con l’integration
test.
Nello specifico ora mi trovo ad avere degli errori RecordNotFound al
punto
1, come se non trovasse il record che stato creato al punto 0. Non
capita
sempre.

-f

2014-10-02 13:11 GMT+02:00 Ju Liu [email protected]:

4

Ho trovato un thread che sembra rientrare nel caso in cui mi trovo.
DatabaseCleaner potrebbe essere responsabile del problema. In
particolare
lo switch tra transaction e truncation.

2014-10-02 13:22 GMT+02:00 Fabrizio R. [email protected]:

5

Fabrizio dovrebbe essere quello, ho avuto lo stesso problema anch’io

–

Maurizio De Santis

Il giorno 02 ottobre 2014 15:14, Fabrizio R. [email protected]
ha
scritto:

6

ho configurato tutto a truncation, togliendo la configurazione per la
transaction. Ora ho un DatabaseCleaner.clean nella config
before(:each).
Ancora problemi del genere per.

-f

2014-10-02 15:16 GMT+02:00 Maurizio De Santis
[email protected]:

7

Thankyou so much. append_after non lo conoscevo. lo switch a truncation
quello che facevo prima. Ora ho corretto la configurazione e usando solo
truncation non ho pi problemi. Probabilmente avevo lo switch tra
transaction e truncation nel modo sbagliato, riprover. E poster la
configurazione.

2014-10-02 15:33 GMT+02:00 Maurizio De Santis
[email protected]:

8

Se ti serve una configurazione funzionante una roba tipo:
Se riesci ad usare :deletion anzich :truncation meglio, almeno se hai
davvero tante tabelle.
Escludi quelle che hai in seeds dalla deletion et voil. Togli tutti gli
sleep (e slip) che fanno male all’ambiente.

RSpec.configure do |config| config.use_transactional_fixtures = false
excluded_tables
= %w[tabella_a tabella_b tabella_seed] config.before(:each) do
ActionMailer
::Base.deliveries.clear Sidekiq::Worker.clear_all end
config.before(:each)
do
DatabaseCleaner.strategy = :deletion, {:except => excluded_tables}
DatabaseCleaner.start
end config.after(:each) do DatabaseCleaner.clean end

Alessandro R.

2014-10-02 15:41 GMT+02:00 Fabrizio R. [email protected]:

9

Rails 4.1.6, RSpec 3.1.0, Sidekiq 3.0.2, DatabaseCleaner 1.3.0, Capybara
2.4.3

RSpec ce l’ho configurato cos (solo le parti relative a Sidekiq e
DatabaseCleaner) e funziona bene (coi test che necessitano Sidekiq
configurati con Sidekiq::Testing.inline!):

Sidekiq

config.before(:suite) do
# Suppress INFO logs such as 2014-08-07T14:07:16Z 24394
TID-otrdqgz00
INFO: Sidekiq client with redis options {}
Sidekiq.logger.level = Logger::WARN
end

config.before(:example) do |example_method|
# Clears out the jobs for tests using the fake testing
Sidekiq::Worker.clear_all
end

DatabaseCleaner

config.before(:suite) do
DatabaseCleaner.clean_with :truncation
end

config.before(:example) do
DatabaseCleaner.strategy = :transaction
end

Extract from

:

Capybara fires up a test server process and drives an actual browser

window via the Selenium backend.

For these types of tests, transactions won’t work, so this code

overrides the setting and chooses the ‘truncation’ strategy instead.
config.before(:example, js: true) do
DatabaseCleaner.strategy = :truncation
end

config.before(:example) do
DatabaseCleaner.start
end

config.append_after(:each) do
DatabaseCleaner.clean
end

–

Maurizio De Santis

Il giorno 02 ottobre 2014 15:21, Fabrizio R. [email protected]
ha
scritto:

10

Interessante questa cosa della deletion, io perdo un sacco di tempo in
truncate nei test!

–

Maurizio De Santis

Il giorno 24 novembre 2014 11:20, Alessandro R. [email protected]
ha
scritto:

11

Io pero’ sposterei il test a livello controller o request lasciando
alle features il controllo di expectations prettamente visualizzabili
via browser.

2014-11-24 5:24 GMT-05:00 Maurizio De Santis
[email protected]:

Se ti serve una configurazione funzionante una roba tipo:
DatabaseCleaner.strategy = :deletion, {:except => excluded_tables}

transaction e truncation nel modo sbagliato, riprover. E poster la

RSpec ce l’ho configurato cos (solo le parti relative a Sidekiq e

config.before(:example) do
browser

ha

[email protected]
[email protected]>

si
determinato
l’integration

Twitter: @arkh4m http://twitter.com/arkh4m

sleep

Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

–
[skype] enrico.teotti
[web] http://teotti.com
[twitter] agenteo