[ANN] Rspec best practices

Ciao ragazzi,

stamattina ho riorganizzato un p di appunti che mi ero messo da parte
negli
ultimi due mesi
ed ho creato un documento che riassume le best
practiceshttps://docs.google.com/document/d/1gi00-wwPaLk5VvoAJhBVNh9Htw4Rwmj-Ut88T4M2MwI/edit?hl=ennell’uso
di RSpec. Riprende alcune
delle nozioni da articoli, libri ed esperienze.

Mi piacerebbe sapere che ne pensate, e siccome il documento accessibile
a
tutti, chiunque
pu inserire commenti ed altre best practices, o scrivere qui, che poi
integrer

Ciao,

Come si scrivono (bene) delle spec per testare il caching a livello
HTTP?
Lo testo facendo lo stub dei metodi di cache e facendo mock dei modelli
in
modo da poter verificare tutto.

Il problema di testare il caching con questo approccio che, per quante
spec io possa scrivere, il mio vero test il log di Apache, che richiede
una verifica manuale :/. Ovviamente non un approccio valido.

Immagino ci siano degli approcci migliori… voi come fate? Lo testate?

Matteo

Il giorno 16 febbraio 2011 14:33, Andrea R.
<[email protected]

ha scritto:

Ciao Matteo,
Parli di Etag, Last-Modified e conditional GET? In questo caso dovresti
controllare gli headers della response.

Luca

2011/2/16 Andrea R. [email protected]:

tutti, chiunque
pu inserire commenti ed altre best practices, o scrivere qui, che poi
integrer

a prima letta mi sembra fantastico e qualcosa che effettivamente
serviva :wink: ti faccio sapere se mi viene in mente qualcosa da
integrare.

ER


Enrico R. /rubbo.li
ELC Tech ™
[email protected]

a prima letta mi sembra fantastico e qualcosa che effettivamente
serviva :wink: ti faccio sapere se mi viene in mente qualcosa da
integrare.

Ottimo, allora aspetto che la discussione di Matteo e Luca si concluda
che poi aggiungiamo la sezione per fare test simulando la cache :slight_smile:

A breve aggiunger anche una sezione per gli shared examples, che
ho usato e che mi han salvato non poche ore.

2011/2/16 Luca G. [email protected]

Ciao Matteo,
Parli di Etag, Last-Modified e conditional GET? In questo caso dovresti
controllare gli headers della response.

S, esatto.

Quindi l’approccio migliore dovrebbe essere:

  1. creare tramite factories (o mock_model) i modelli che mi servono.
  2. scrivere le spec per i “nuovi dati”, senza header HTTP.
  3. effettuare le chiamate con gli header HTTP settati, e osservare che
    mi
    venga restituito un 304.

Giusto?

Matteo

Sicuramente sar usato :slight_smile:

Alla fine credo sia normale che nel libro ci siano modi di usi diversi.
Alla
fine
vanno scritti come ce li sentiamo, cos che quando li leggiamo siano
chiari,
o
almeno questa la mia idea :slight_smile:

Ma dimmi, quali sono le differenze principali che hai visto?

P.S. dovrai farci un resoconto di service oriented design with ruby and
rails

2011/2/17 Duncan [email protected]

Il giorno 16 febbraio 2011 14:33, Andrea R.
<[email protected]

ha scritto:

delle nozioni da articoli, libri ed esperienze.
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

Quindi useremo RSpec per il progetto Hack For School?
Ho cominciato ad usarlo leggendo il libro service oriented design with
ruby
and rails
Per lo usa in modo un po’ diverso dagli esempi che hai fatto tu.


Mentre noi dormiamo, il dolore che sempre presente in noi cade goccia
a goccia sul nostro cuore, finch contro la nostra stessa volont, la
maestosa grazia di Dio non converte in saggezza la nostra disperazione
(ESCHILO)

L’esperienza quello che ottieni quando, non ottieni quello che
desideri.

Altra domanda questa volta molto specifica ad rspec-rails 2.

Il generator crea una cartella /spec/requests.

Che tipo di spec vengono scritte all’interno di quella cartella?

Matteo

Il giorno 16 febbraio 2011 14:33, Andrea R.
<[email protected]

ha scritto:

2011/2/18 Matteo C. [email protected]

Altra domanda questa volta molto specifica ad rspec-rails 2.
Il generator crea una cartella /spec/requests.
Che tipo di spec vengono scritte all’interno di quella cartella?

Non li ho mai usati, ma da quel che ho letto (RSpec book non ne parla)
io li
userei per
fare integration tests.

In ogni caso, quello che si fa richiamare un URL e poi esaminare i
valori
che ne ritornano
o il behavior. L’esempio proposto questo.

it "contains the widgets header" do
  get "/widgets/index"
  response.should have_selector("h1", :content => "Widgets")
end

Ma si pu verificare il redirect, e verificare quello che riguarda il
controller (tipo flash, session
instance variables and so on).

C

Il giorno 17 febbraio 2011 00:01, Matteo C.
[email protected]ha scritto:

Quindi l’approccio migliore dovrebbe essere:

  1. creare tramite factories (o mock_model) i modelli che mi servono.
  2. scrivere le spec per i “nuovi dati”, senza header HTTP.
  3. effettuare le chiamate con gli header HTTP settati, e osservare che mi
    venga restituito un 304.

Ho un problema nel settare gli headers per la richiesta. Ho provato:

request.headers[“HTTP_IF_MODIFIED_SINCE”] = (Time.now - 1.day).utc
request.headers[“HTTP_CACHE_CONTROL”] = “public”
request.headers[“ETAG”] = @object.hash

e

request.headers[“If-Modified-Since”] = (Time.now - 1.day).utc
request.headers[“Cache-Control”] = “public”
request.headers[“etag”] = @object.hash

Ma l’unica cosa che ottengo dentro alla action del controller :

puts headers.inspect
=> {“Cache-Control”=>“no-cache”}

Avete qualche suggerimento?
Qualcuno l’ha mai fatto?

(Sto usando rspec 1.3, purtroppo :()

Matteo