A qualcuno piace la nuova (forse non cos nuova) sintassi rspec
expect(foo).to eq bar
???
a me comincia a dare ai nervi, forse perch mi ero abituato a
foo.should eq bar
a questo punto mi pare meglio
assert_equal foo, bar
Che dite?
Il giorno 16/set/2014, alle ore 16:35, David W.
[email protected] ha scritto:
Avranno dei motivi, anche validi, ma…
non mi diverto a fare quel tipo di modifica cosi` spesso.
ho ritrovato questo vecchio articolo, spiega a grandi linee le
motivazioni del cambio di sintassi:
http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
ciao,
A.
–
2014-09-16 16:30 GMT+02:00 Fabrizio R. [email protected]:
A qualcuno piace la nuova (forse non cos nuova) sintassi rspec
expect(foo).to eq bar
???
a me comincia a dare ai nervi, forse perch mi ero abituato a
foo.should eq bar
A volte nel mondo Ruby mi sembra che ci sia un po’ troppo “cambiare
per il gusto di cambiare”. Avranno dei motivi, anche validi, ma…
non mi diverto a fare quel tipo di modifica cosi` spesso.
–
David N. Welton
Grazie Andrea, sicuramente interessante l’articolo, mi sembra di averlo
letto sommariamente tempo fa. Sicuramente le ragioni per il cambiamento
sono valide.
La mia era pi una considerazione linguistica.
Altra cosa che mi da i brividi la nuova sintassi con cui si verifica
true
o false.
Prima
foo.should == true
bar.should == false
incluse le varianti should be false, should be true etc.
Dopo:
expect(foo).to be
expect(bar).not_to be
Di chiara ispirazione Shakespeariana. Da metterci un bel teschio in
ASCII
art quando i test non passano (o quando passano? questo il problema…)
2014-09-16 16:39 GMT+02:00 Andrea P. [email protected]:
Il giorno 17/set/2014, alle ore 08:55, Fabrizio R.
[email protected] ha scritto:
Dopo:
expect(foo).to be
expect(bar).not_to be
+1, anche a me non piace, se non altro perch poco chiara 
di norma, uso questa sintassi, di fatto equivalente:
expect(foo).to be_true
expect(bar).to_not be_false
expect(baz).to be_false
ciao,
A.
–
Ciao a tutti,
sono nuovo della mailing list 
Io preferisco expect a should, perch should inquina il namespace
globale.
Ci nonostante l’obiezione “a sto punto uso assert_” penso sia valida,
anche se “expect(something).to eq something_else” secondo me rimane pi
leggibile di “assert_equal something, something_else”.
Comunque per chi dovesse upgradare ad una nuova versione di RSpec
segnalo
questo tool formidabile: GitHub - yujinakayama/transpec: The RSpec syntax converter Per me
stato una salvezza!
–
Maurizio De Santis
2014-09-17 9:37 GMT+02:00 Andrea P. [email protected]:
Ci nonostante l’obiezione “a sto punto uso assert_” penso sia valida,
anche se “expect(something).to eq something_else” secondo me rimane pi
leggibile di “assert_equal something, something_else”.
A me non piace molto lo pseudo-inglese, penso che sia un concetto che
crei piu confusione che altro, e trovo assert_ molto piu chiaro e in
linea con gli altri linguaggi che uso/ho usato. Se altrove in Ruby
uso ‘foo == true’, lo voglio usare anche nei miei test! Lascio il
please.be_true! a Frank Sinatra…
–
David N. Welton
io non ho mai capito perch
a.should equal(x)
fosse meglio di
assert_equal a, x
a parte vari deliri astratti che “cos meglio”.
Rimango fautori del perlismo
is a, b
2014-09-16 16:30 GMT+02:00 Fabrizio R. [email protected]:
a questo punto mi pare meglio
assert_equal foo, bar
Che dite?
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
twitter: @riffraff
blog (en, it): www.riffraff.info
work: circleme.com
[era rimasta in outbox]
ricordo di aver letto che uno dei benefici del cambio di sintassi
che l’implementazione che ci sta dietro pi lineare e riduce il ricorso
al patching e riapertura delle classi base (e/o rails) con ovvia
riduzione
di side-effects.
Mi spiace non essero pi preciso, ho (ri)cercato la fonte senza successo.
m.
Il giorno 16 settembre 2014 16:39, Andrea P. [email protected] ha
scritto:
Basically perche’ si legge meglio 
La bellezza di Ruby, come
Smalltalk,
e’ che il codice (se scritto bene) si puo’ leggere come prosa.
Idealmente
robe come parentesi, puntini, pallini, sbirulini sarebbero da evitare
(come
si dice, “you are spoon-feeding the compiler”). Ancora di piu’ si devono
leggere bene i test (rspec) che costituiscono di fatto l’unica forma
aggiornata di documentazione del nostro codice.
Gli esempi precedenti della “nuova sintassi” mi sembrano meno leggibili
e
meno chiari come prosa, hence mi piacciono meno. Pero’ nn sono un
programmatore ruby, quindi prendete le mie opinioni specifiche su questo
aspetto di rspec con le molle
Cheers,
Bruno
Il giorno 17/set/2014, alle ore 12:17, gabriele renzi
[email protected] ha scritto:
io non ho mai capito perch
a.should equal(x)
fosse meglio di
assert_equal a, x
a parte vari deliri astratti che "cos meglio.
probabilmente perch permette di esprimere meglio il comportamento del
codice attraverso matchers scritti ad hoc. cito un paio di esempi
(https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers/predicate-matchers):
expect(x).to be_multiple_of(3)
expect(array).not_to have_odd_values
ovviamente puoi scriverli in altri modi, anche usando assert, ma con
rspec IMHO pi pulito
ciao,
A.
–
Andrea: ok, ma quello sposta solo la domanda al passo dopo: perché è
meglio
di
assert_multiple_of_3 x
assert_no_odd_values array
Ma ovviamente son d’accordo, sono gusti.
Bruno: appunto preferisco la sintassi di test/unit
assert_foo a, b # una virgola
a.should be_foo(b) # un punto, due parentesi
Ri-rilancio: ma la vostra opinione sulla sintassi stile
assert{2.0}/wrong
[0][1] ?
[0] O'Reilly Media - Technology and Business Training
[1] GitHub - sconover/wrong: Wrong provides a general assert method that takes a predicate block. Assertion failure messages are rich in detail.
Per chi non se la ricordasse, era
assert { a == b } # a.should eq(b)
assert { a % 3 == 0 } # assert_multiple_of_3
assert { not odd_values(3) } # expect(array).not_to have_odd_values
Il vantaggio rispetto a assert_xxx o custom matcher è: si possono
metetre
inline espressioni arbitrarie “senza perdere insight”, cioè, Il
vantaggio
rispetto a fare
assert (tutta la expr tra parentesi)
(tutta tra parentesi).should be_true
è la gestione intelligente del messaggio di errore “expected a == b to
be
true” invece che “got false expected true”
O, nel caso di Wrong
assert { 2 == 1 }
==> Expected (2 == 1), but 2 is not equal to 1
Ora, 7 anni fa era fatto tutto a colpi di hack, ma oggi c’è
Proc#source_location che lo renderebbero abbastanza più sano
2014-09-17 16:36 GMT+02:00 Andrea P. [email protected]:
Il giorno 17/set/2014, alle ore 12:17, gabriele renzi [email protected]
ha scritto:probabilmente perchè permette di esprimere meglio il comportamento del
codice attraverso matchers scritti ad hoc. cito un paio di esempi (
https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers/predicate-matchers
):expect(x).to be_multiple_of(3)
expect(array).not_to have_odd_valuesovviamente puoi scriverli in altri modi, anche usando assert, ma con
rspec IMHO è più pulito
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
twitter: @riffraff
blog (en, it): www.riffraff.info
work: circleme.com
Riempire il codice di expect non mi piace molto, ma pazienza.
Più che altro il problema è riscrivere tutti i test vecchi, che è quasi
intrattabile.
Ci ho sbattuto contro a giugno e ho scritto
Per farla breve
config.expect_with :rspec do |c|
c.syntax = [:should, :expect]
end
più un altro paio di salvavita che trovate nel post.
Io ho usato con soddisfazione Transpec – The RSpec Syntax Converter
Non usa regular expression, ma fa sia static code analysis (analizza i
file
ruby) che dynamic code analysis (lancia il codice e osserva le
chiamate).
L’ho trovato un progetto fantastico!
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-09-18 14:34 GMT+01:00 Fabrizio R. [email protected]:
NOOOO, ma che figata pazzesca ?!
On 18 Sep 2014, at 15:53, Ju Liu [email protected] wrote:
Io ho usato con soddisfazione Transpec – The RSpec Syntax Converter
Non usa regular expression, ma fa sia static code analysis (analizza i file
ruby) che dynamic code analysis (lancia il codice e osserva le chiamate).
L’ho trovato un progetto fantastico!Ju
–
Stefano V.
CTO @ Cantiere Creativo snc
Telefono: 055 2345008
Skype: steffoz
Si il fatto di riscrivere gli should in expectations pesante. I test
inoltre potrebbero fallire silenziosamente se fai qualche errore, a meno
di
non passare per il red per ognuno di essi.
2014-09-18 15:21 GMT+02:00 Paolo M. [email protected]:
wrong mi sembra molto interessante, non lo conoscevo!
transpec sta proprio avanti O.O
–
Maurizio De Santis
Il giorno 18 settembre 2014 15:34, Fabrizio R. [email protected]
ha
scritto:
fwiw, io ho scoperto giorni fa synvert[0] che invece fa rimpiazzi solo
sintattici ma ha una dozzina di regole per rspec, forse vi utile
[0] http://xinminlabs.github.io/synvert/examples/
2014-09-18 16:00 GMT+02:00 Maurizio De Santis
[email protected]:
scritto:
Pi che altro il problema riscrivere tutti i test vecchi, che quasi
c.syntax = [:should, :expect]
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
–
twitter: @riffraff
blog (en, it): www.riffraff.info
work: circleme.com
Scusate se riapro la thread ma proprio oggi mi sono messo ad aggiungere
dei nuovi test al progetto che settimane fa avevo riconfigurato perché
funzionasse con rspec 3 senza troppe modifiche.
Ho iniziato a usare expect per i nuovi test e quando mi sono messo a
trasformare i vecchi ho scoperto che la sintassi
expect(oggetto.attributo).to eq(valore) non mi piace per niente.
Una fila infinita di expect() mi ricorda troppo le file infinite di
array() e $this-> che mi è capitato di trovare in un linguaggio
diversamente rubistico. Il troppo rumore rende il codice illeggibile.
Preferisco avere la fila infinita di .should == a destra, dove si nota
meno e non nasconde l’oggetto del test, che rimane ben in evidenza a
sinistra.
Ho (ri)letto il post linkato in uno dei primi messaggi della thread
http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax e
ne capisco le intenzioni. Secondo me è una cura da usare solo quando è
indispensabile e i should non possono funzionare.
Usare assert() al posto di expect() non migliorerebbe di molto le cose,
ci risparmieremmo solo il .to be() Qualcosa si guadagna ma il rumore
resta.
Morale: sto rimettendo gli should dove avevo messo gli expect
Mah. Si usano parole come ‘recommend’ e ‘upgrade’ nei confronti di
‘expect’. Mi pare una deprecation mal celata.
2014-09-20 0:34 GMT+02:00 Elia S. [email protected]: