Etunimetensin

[jkpj]

Olit jo tehnyt helper-metodiin sen etunimi ensin -kohdan. Sen sijaan että olisin muokannut kymmentä kohtaa view-puolella, tein helper-metodiin lisäehdon joka määrittää, että etunimi on aina ensin. Tämän metodi käyttää sovellusvakiota, jolloin oletusta on helppo muuttaa yhtä paikkaa muuttamalla. Ja on helppo lisätä konfiguroitavuus käyttäjälle jos haluat.

[karhatsu]

Iso kasa cucumber-testejä ei mene läpi (kuten etukäteen varoittelin). Onhan nuo helppo korjata mutta onkohan tämä sittenkään järkevä muutos..?

[jkpj]

Hmm, ei ilmeisesti olisi varsinaisesti korrektia, mutta yksinkertainen tapa ratkaista asia ja sallia etunimen käyttö ensin olisi stubata cucumber-ajoa varten always_first_name_first -metodi. En kyllä tiedä miten ja missä tämä tehtäisiin.

stub!(:always_first_name_first?).and_return(false)

25.03.2011 12:16, karhatsu kirjoitti:

Iso kasa cucumber-testejä ei mene läpi (kuten etukäteen varoittelin). Onhan nuo helppo korjata mutta onkohan tämä sittenkään järkevä muutos..?

[karhatsu]

Ei kuulosta hyvältä. Cucumber on integraatiotestien työkalu, eikä siinä stubailla, ellei ole pakko. Esimerkkinä järjestelmän käyttäytyminen eri tavalla staging/production-ympäristöissä.

Jos alkuperäinen tarve oli se, että tuloslistoissa olisi etunimi ensin, niin miksi ei muuteta vain sitä osaa? En näe suurta hyötyä tällaisesta globaalista vakiosta, joka vaikuttaa joka paikkaan.

Toisaalta kyse on kuitenkin niin triviaalista asiasta, että menisi ylikustomoinniksi, jos käyttäjä saisi valita nimien järjestyksen. Ja ylipäätään koko alkuperäinen tarve on vähän arveluttava. Ei kai se nimien lukeminen voi niin vaikeaa olla..?

[jkpj]

Huomautit tuosta pelkästään tuloslistoihin muuttamisesta, että ei oikein tunnu järkevältä että on eri lailla eri paikoissa, ja taidanpa kallistua siinä samalle kannalle.

No, jätetäänpä tämä sitten pois. Periaatteessa järjestelmätason nimien järjestyksen valinta olisi minusta ihan hyödyllinen ja sinänsä vähän hassua että näin yksinkertainen muutos onkin integraatiotesteissä hankala. Tai niin, jos oikein hahmotan, niin kyllähän tuo tietysti on ratkaistavissa löytyisi hiukan regexpejä ym. kirjoittelemalla steppeihin, mutta enpä ala tuota ainakaan vielä tekemään. Tosin voisihan tuo olla ihan opettavainen harjoitus tehdä tunnistus molemmissa järjestyksissä, mutta olisiko tuokaan sitten integraatiotestin idean mukaista? Toisaalta miksipä ei olisi? Tarkoitan siis, että tekisi testeistä sellaiset että hyväksyvät nimen kummassa järjestyksessä vain.

25.03.2011 13:44, karhatsu kirjoitti:

Ei kuulosta hyvältä. Cucumber on integraatiotestien työkalu, eikä siinä stubailla, ellei ole pakko. Esimerkkinä järjestelmän käyttäytyminen eri tavalla staging/production-ympäristöissä.

Jos alkuperäinen tarve oli se, että tuloslistoissa olisi etunimi ensin, niin miksi ei muuteta vain sitä osaa? En näe suurta hyötyä tällaisesta globaalista vakiosta, joka vaikuttaa joka paikkaan.

Toisaalta kyse on kuitenkin niin triviaalista asiasta, että menisi ylikustomoinniksi, jos käyttäjä saisi valita nimien järjestyksen. Ja ylipäätään koko alkuperäinen tarve on vähän arveluttava. Ei kai se nimien lukeminen voi niin vaikeaa olla..?

[karhatsu]

No ehkä niin, että kilpailukohtaisesti voisi vaihtaa mutta ei niin, että palvelinkohtaisesti vaihdetaan välillä toiseksi ja sitten toiseksi. Ja mitä taas tulee kilpailukohtaisuuteen, niin sitten puhutaan siitä ylikustomoinnista. Ei kaikkea tarvitse tehdä, mitä käyttäjät pyytävät. Se on eri asia, jos monesta suunnasta tulee pyyntöä.

Se regex-ratkaisu olisi muuten aika paha code smell. Ja itse asiassa kertoo siitä, että toteutuksessa on jotain pielessä, jos sellaiseen jouduttaisiin. Älä siis missään nimessä ala tekemään sellaista.

Suljen tämän nyt joka tapauksessa.

[jkpj]

OK, tosin näin äkkipäätä tulee myös mieleen, onko testialustassa jotain pielessä jos ei tällaista kuitenkin yksinkertaista muutosta saa järkevästi testeihin ;)

25.03.2011 14:41, karhatsu kirjoitti:

No ehkä niin, että kilpailukohtaisesti voisi vaihtaa mutta ei niin, että palvelinkohtaisesti vaihdetaan välillä toiseksi ja sitten toiseksi. Ja mitä taas tulee kilpailukohtaisuuteen, niin sitten puhutaan siitä ylikustomoinnista. Ei kaikkea tarvitse tehdä, mitä käyttäjät pyytävät. Se on eri asia, jos monesta suunnasta tulee pyyntöä.

Se regex-ratkaisu olisi muuten aika paha code smell. Ja itse asiassa kertoo siitä, että toteutuksessa on jotain pielessä, jos sellaiseen jouduttaisiin. Älä siis missään nimessä ala tekemään sellaista.

Suljen tämän nyt joka tapauksessa.

[karhatsu]

Tällainen pitäisi testata niin, että on jokin oletusarvo, joka ei muutu. Kaikki testit nojaisivat tuohon arvoon. Sitten olisi yksi testi, joka testaisi oletusarvon muuttumisen vaikutuksen. Näin tehtäisiin esim lokalisoinnin testaus. Jos järjestelmään tulisi ruotsin kieli, niin kaikki testikoodi olisi suomidatalla paitsi yksi skenaario testaisi lokalisaation vaihtumisen.

Ongelma tulee siinä, jos oletusarvo saattaakin vaihtua. Voi sen toki kerran vaihtaa, jolloin voidaan muuttaa kaikki testit. Mutta jos on mahdollista, että oletusarvo muuttuu kohta uudestaan, niin sitten kyse ei ole oikeasti oletusarvosta. Tähän perustuu se, että regex olisi code smell ja että vika onkin jossain muualla. (Ja huomasin kyllä sen hymiön mutta halusin silti selittää tämän.)