Capybara velocità test integrazione

addis_a · November 11, 2014, 7:10pm

E’ normale avere 6 test di integrazione che impiegano 1 minuto e 14
secondi?
Sto cercando di capire se normale il tempo della mia suite o c’
qualcosa
che non va.

fregini · November 11, 2014, 7:21pm

normale se non usi driver headless per cui la suite apre il browser con
conseguenti tempi lunghi; in alternativa puoi usare per l’appunto driver
headless come phantom, ma devo dire che non c’ho mai provato
Il 11/nov/2014 19:09 “Fabrizio R.” [email protected] ha scritto:

fregini · November 11, 2014, 7:52pm

Dipende da quanti step ci sono in questi 6 test, a naso comunque direi
che
no, non normale per nulla

Il giorno 11 novembre 2014 19:36, Fabrizio R. [email protected]
ha
scritto:

fregini · November 11, 2014, 7:36pm

uso capybara-webkit.

2014-11-11 19:21 GMT+01:00 Maurizio De Santis
[email protected]:

fregini · November 11, 2014, 8:49pm

Do un p di contesto in pi. Si tratta di una applicazione che pubblica un
third party javascript, e i test di integrazione in pratica fanno quanto
segue:

invocano una pagina (come un normale test di integrazione)
la quale pagina invoca il third party javascript facendo un’altra
chiamata allo stesso capybara
compie azioni nella pagina che tramite javascript mandano a capybara
degli eventi che devono essere registrati

Quindi sicuramente complesso gi di suo. Morale della favola solo i test
di integrazione impiegano 15 minuti per 114 esempi.
Sto cercando modi per velocizzare i test di integrazione. Qualcuno ha
fatto
esperienza con librerie per mandare in parallelo i test?

-f

2014-11-11 19:51 GMT+01:00 Stefano V. [email protected]:

fregini · November 11, 2014, 8:55pm

----- Messaggio originale -----
Da: “Fabrizio R.” [email protected]
Inviato: ‎11/‎11/‎2014 20:48
A: “ruby-it” [email protected]
Oggetto: Re: [ruby-it] Capybara velocità test integrazione

Do un pò di contesto in più. Si tratta di una applicazione che pubblica
un
third party javascript, e i test di integrazione in pratica fanno quanto
segue:

invocano una pagina (come un normale test di integrazione)
la quale pagina invoca il third party javascript facendo un’altra
chiamata allo stesso capybara
compie azioni nella pagina che tramite javascript mandano a capybara
degli eventi che devono essere registrati

Quindi sicuramente è complesso già di suo. Morale della favola solo i
test
di integrazione impiegano 15 minuti per 114 esempi.
Sto cercando modi per velocizzare i test di integrazione. Qualcuno ha
fatto
esperienza con librerie per mandare in parallelo i test?

-f

2014-11-11 19:51 GMT+01:00 Stefano V. [email protected]:

:

secondi?
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

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

fregini · November 11, 2014, 9:00pm

Ciao,
Ma hai necessita di usare capybara? Devi agire sugli elementi della
pagina o ti basterebbe agire sul codice javascript della libreria di
terzi?
Se devi agire solo sul codice js potresti scrivere i testi in javascript
con mocha o altre librerie di test javascript e poi usare thrill.js o
karma per parallelizzare i test su più browser. Ma dipende da quello che
devi fare.
Io vedo capybara utile per fare test su web app su più pagine.

----- Messaggio originale -----
Da: “Fabrizio R.” [email protected]
Inviato: ‎11/‎11/‎2014 20:48
A: “ruby-it” [email protected]
Oggetto: Re: [ruby-it] Capybara velocità test integrazione

Do un pò di contesto in più. Si tratta di una applicazione che pubblica
un
third party javascript, e i test di integrazione in pratica fanno quanto
segue:

invocano una pagina (come un normale test di integrazione)
la quale pagina invoca il third party javascript facendo un’altra
chiamata allo stesso capybara
compie azioni nella pagina che tramite javascript mandano a capybara
degli eventi che devono essere registrati

Quindi sicuramente è complesso già di suo. Morale della favola solo i
test
di integrazione impiegano 15 minuti per 114 esempi.
Sto cercando modi per velocizzare i test di integrazione. Qualcuno ha
fatto
esperienza con librerie per mandare in parallelo i test?

-f

2014-11-11 19:51 GMT+01:00 Stefano V. [email protected]:

:

secondi?
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

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

fregini · November 11, 2014, 9:05pm

Ciao,
si, in effetti usare capybara per testare una liberia javascript non è
il
massimo. Sicuramente quello rende tutto più gravoso. C’è da dire che
testare il javascript con Capybara è più facile (clicca qui, clicca lì)
ma
probabilmente i test si possono sfoltire testando il javascript
separatamente. Cosa che non so fare. Quindi mi sa che mi devo mettere a
studiare il test unit per javascript cosa che ho lungamente rimandato…

2014-11-11 20:59 GMT+01:00 francesco agati
[email protected]:

fregini · November 11, 2014, 9:14pm

Come librerie puoi vedere mocha, Jasmine, che sono compatibili con
diversi sistemi che fanno girare i test in parallelo su piu browser.
Thrill, karma e altri.
Purtroppo ti devo dire che sono fatti quasi tutti con node.
Se scegli la libreria di testing controlla che sia compatibile con i
sistemi di parallelizzazione di testing.
Io personalmente per scrivere i test preferisco usare CoffeeScript o
livescript per velocità di scrittura.

I test asincroni in js sono una brutta bestia

----- Messaggio originale -----
Da: “Fabrizio R.” [email protected]
Inviato: ‎11/‎11/‎2014 21:05
A: “ruby-it” [email protected]
Oggetto: Re: [ruby-it]R: Capybara velocità test integrazione

Ciao,
si, in effetti usare capybara per testare una liberia javascript non è
il
massimo. Sicuramente quello rende tutto più gravoso. C’è da dire che
testare il javascript con Capybara è più facile (clicca qui, clicca lì)
ma
probabilmente i test si possono sfoltire testando il javascript
separatamente. Cosa che non so fare. Quindi mi sa che mi devo mettere a
studiare il test unit per javascript cosa che ho lungamente rimandato…

2014-11-11 20:59 GMT+01:00 francesco agati
[email protected]:

Da: “Fabrizio R.” [email protected]
chiamata allo stesso capybara

headless come phantom, ma devo dire che non c’ho mai provato

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

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

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

fregini · November 11, 2014, 9:29pm

Queste osservazioni aprono una tematica più generale molto molto
interessante per me (spero di non diventare OT, ma so già di esserlo)…

Quali sono le vostre esperienze sul testare in integration applicazioni
o
componenti fortemente client side? Come la vivete?

Perchè ben venga lo unit testing lato JS, ma non è sufficiente per avere
un
qualche tipo di certezza di risultato end-to-end. Che
metodi/strumenti/pratiche utilizzate per essere tranquilli che quello
che
state facendo funzioni, e che non funzioni solo su webkit, ma su gli N
altri browser (mobile e non)?

Io, personalmente soffro, e ho la sensazione di essere tornato nel
medioevo.

Il giorno 11 novembre 2014 21:13, francesco agati <
[email protected]> ha scritto:

fregini · November 11, 2014, 10:12pm

già che siamo OT magari questo interessa:

" Rebuilding the Shopify Admin: Improving Developer Productivity by
Deleting 28,000 lines of JavaScript":

non dico che vale per tutti e sempre, ma trovo sia una riflessione molto
interessante

fregini · November 11, 2014, 11:40pm

Se hai molto codice JS ti consiglio anch’io di testarlo a sé stante
usando ad esempio Jasmine. Questo significa sganciare quanto più codice
possibile dal DOM e dalle chiamate Ajax al server, ma se il codice è
tanto avrai tante classi che si prestano a unit test. E se hai
un’applicazione JS, testala in JS e non in Ruby

L’integrazione poi ti servirà lo stesso e in quanto a Capybara ho notato
che sono molto lente tutte le fill_in “campo”, with: “stringa” perché
cercano di simulare la velocità di scrittura di una persona. Se hai
molte input box o textarea grosse che riempi con paragrafi di lorem
ipsum, è un bel problema. Per il resto un browser headless è più rapido
di uno “reale”. Uso la gemma selenium-webdriver che pilota sia Firefox
che Chrome, con la gemma headless. Apparentemente funziona anche con i
test in parallelo (vedi verso la fine di
GitHub - leonid-shevtsov/headless: Create a virtual X screen from Ruby, record videos and take screenshots.) ma non l’ho mai provato.

fregini · November 13, 2014, 7:07am

Fabrizio,
Sarò in controtendenza rispetto alle altre risposte di questo thread, ma
ti consiglio di usare Capybara con Webkit.

Ho usato Jasmine un po’ di tempo fa. Il problema principale è quello di
mantenere gli unit test. Essi necessitano di fixtures che riflettano il
tuo markup dei templates. Col passare del tempo diventa costoso tenere
le due cose sincronizzate.

Questi test non sempre funzionano bene e molto spesso ti spingono a
scrivere JS ad oggetti, anche quando il comportamento che vuoi testare
non lo richiederebbe.
Ai fini pratici, ad esempio, un observer espresso con questa sintassi è
più che sufficiente $(‘#my-select-tag’).on(‘change’, function(){ … });. Questo però non è un oggetto, per cui diventa difficile testarlo
con Jasmine.

Capybara ti garantisce un test di integrazione che simula la user
experience. Ne hai comunque bisogno, con o senza Jasmine.

La tua suite è lenta, invece di eliminare il problema dei test, cerca di
capire qual è la ragione.

Luca

fregini · November 13, 2014, 9:50am

Ciao Luca,
grazie da un certo punto di vista la cosa mi conforta. Nel senso che il
javascript per questa applicazione ha poco i OO e molto di funzionale. E
comunque i test che ho adesso anche se lenti mi danno una enorme
sicurezza
rispetto al funzionamento del sistema.
Un’idea che ho riguardo la lentezza è il fatto che la pagina che sto
testando deve attendere il caricamento in webkit di un javascript
asincrono
che simulo provenire da un altro dominio.
Schematicamente lo riassumo così:

visita la pagina (Capybara risponde come host X)
la pagina include un javascript che che è simulato provenire da un
altro
dominio Y ma che fa capo sempre a Capybara. Questo inculde a sua volta:
- jquery se questo manca o non è compatibile
- easyXDM
  - easyXDM a sua volta, per poter funzionare, ha bisogno da
    caricare sotto il dominio di destinazione (Y).
- legge dei parametri da un segnaposto e carica un altro javascript
  con
  il codice da eseguire (A)
- carica un css
Il codice (A) una volta caricato modifica il DOM e mostra un widget
nella
pagina
Le azioni dell’utente nel widget generano degli eventi che devono
essere
inviati via easyXDM e raccolti dallo stesso Capybara sul dominio Y

Gli eventi che raccolgo sul dominio Y vengono messi in coda con Sidekiq.

Uno dei test tipici e di grande valore di questa applicazione è
assicurarsi
che tutto questo giro funzioni, dal momento del click nel widget al
momento
della registrazione dell’evento nel database tramite Sidekiq.
Scrivendo questo schema mi sto rendendo conto che probabilmente non
posso
chiedere troppo vista la quantità di file esterni caricati.

-f

2014-11-12 9:53 GMT+01:00 Luca G. [email protected]:

fregini · November 13, 2014, 11:06am

Fabrizio,
Non vedo come potresti testare diversamente il workflow di tutti questi
componenti.

I test sono sempre un indicatore dello stato di “salute"
dell’applicazione.
In questo caso la complessità della feature rallenta i test. Il che mi
porta a pensare che la user experience potrebbe risultare ugualmente
lenta.

Quindi “ascoltare” i test potrebbe aiutarti a semplificare la feature
stessa, in modo da non sacrificare le performance per i tuoi utenti.
Ovviamente sta a te giudicare. Quello che voglio dire è che i test sono
uno spunto di riflessione.

Luca

fregini · November 14, 2014, 9:56am

Ma i driver headless per Capybara come questo
GitHub - teampoltergeist/poltergeist: A PhantomJS driver for Capybara non li hai mai provati
nessuno? Dovrebbero essere la svolta, ma non mi ci sono mai messo a
provarli

fregini · November 14, 2014, 10:05am

mi risulta che capybara-webkit sia headless. Poltergeist l’ho provato ma
ho
sempre avuto problemi. Capybara webkit decisamente il pi affidabile che
abbia mai provato.

On Thu, Nov 13, 2014 at 4:53 PM, Maurizio De Santis <

fregini · November 14, 2014, 10:07am

Pardon, pensavo fosse il driver che si interfaccia con Chrome

–

Maurizio De Santis

Il giorno 13 novembre 2014 17:02, Fabrizio R. [email protected]
ha
scritto:

fregini · November 14, 2014, 10:16am

Se avete problemi con AJAX e Capybara, ecco uno snippet utile:

gist.github.com

https://gist.github.com/jodosha/47a88c2803da6a8055d1

ajax_helpers.rb

# Credits:
#
#   * http://robots.thoughtbot.com/automatically-wait-for-ajax-with-capybara
#   * https://coderwall.com/p/aklybw
require 'timeout'

module RSpec::Features
  module AjaxHelpers
    def wait_for_ajax
      Timeout.timeout(Capybara.default_wait_time) do

This file has been truncated. show original

Luca

fregini · November 15, 2014, 2:52pm

http://robots.thoughtbot.com/speed-up-javascript-capybara-specs-by-blacklisting-urls;)