Code Wars, mahdollisuus oppia

Tutustuin codewarsiin työkaverini suosituksesta yhtenä syksyisenä päivänä. Hän löysi koodiharjoitussivuston, jossa editoria ja testejä voi ajaa selaimen kautta. Toisin kuin exersim.io tai vastaavissa palveluissa, codewarsilla harjoitteleminen onnistuu ilman kehitysympäristöä.

Harjoitusten tekeminen codewarsissa käy helposti. Harjoitusta kutsutaan nimellä kata.

Kata eli harjoitus codewars.com:ssa.

 

Harjoituksen tehtävänanto selviää ruudun vasemmalta puolelta. Koodi kirjoitetaan oikeassa yläkulmassa näkyvään koodinäkymään. Kirjoitettu koodi ajetaan ”paikallisia” testejä vastaan Run Examples -painikkeella. Ne löytyvät Example Tests -otsikon alta. Näitä testejä voi myös muokata omien mieltymysten mukaan.

Lopullinen testi ratkaisulle tehdään ajamalla koodi Attempt-painikkeella. Ratkaisun toimivuus testataan yksikkötesteillä, joita ei näytetä käyttäjälle. Vain testien tulos näytetään. Toisinaan testien nimestä voi päätellä mikä testi epäonnistui. Järjestelmä sallii myös satunnaistettujen testien ajamisen, jolloin tehtävän luojan ei tarvitse kirjoittaa kaikkia testitapauksia käsin.

Ratkaistuasi tehtävän, saat vaikeusasteen mukaan tietyn määrän pisteitä. Helpoimmat testit saa ratkaistua muutamassa minuutissa, vaikeampien ratkaiseminen kestää tunteja.

Ratkaistuasi tehtävän, näet muiden vastaukset ja näistä oppii. Vastauksista voi merkata omasta mielestä parhaan ja nokkelan vastauksen. Vastauksista näkee kuinka paljon ohjelmoijien ongelmanratkaisukyky ja API-tuntemus vaihtelee.

Stats-sivu kertoo mistä olet saanut pisteitä.

 

Olen kerännyt suurimman osan pisteistäni tekemällä harjoituksia. Pisteiden hankkimiseen käytetyt kielet näkyvät oikeasta laidasta ja prosenttiosuus kertoo kuinka paljon pisteitä on kerätty ennen seuraavaa tasoa.

Pisteet päivittyvät muutaman tunnin välein, kun palvelin ajaa ajastetusti pisteiden päivistyskriptit. Itsekin ihmettelin aluksi miksi pisteet päivittyvät viiveellä.

Jos teet vain harjoituksia, pisteillä ei ole merkitystä. Halutessasi voit kirjoittaa harjoituksia muiden ratkaistavaksi tai kääntää niitä kieleltä toiselle. Tällöin korkeampi pistemäärä sallii kevyemmän validointiprosessin ennen kuin kirjoittamasi harjoitus julkaistaan.

Yhteisöllisyyttä yritetään lisätä klaanien avulla. Käyttäjän tiedoissa voi antaa itselleen klaanin. Se on vain merkkijono. Kaikki jotka kirjoittavat saman merkkijonon, tulevat samaan klaaniin.

Klaanit

 

Klaanijärjestelmä ei ehkä ole täydellinen, koska vaihdettuani klaanin, näen edelleen kaikki vanhan klaanini jäsenet.

Codewars on ehdottomasti paras palvelu ohjelmointiharjoitusten tekemiseen. Sen avulla voi ylläpitää kielen osaamista tai opetella uutta kieltä. Toki harjoitusten avulla oppii erityisesti kielen käyttöä, ei niihin liittyvien frameworkkien käyttöä.

Suosittelen kokeilemaan codewarsia, sen avulla voit löytää palon vanhaan rakkaaseen kieleen tai kehittää osaamistasi nykyisen kielen kanssa.

 

 

 

Miksi kirjoittaa yksikkötestejä?

Olen kirjoittanut yksikkötestejä n. 7 vuotta. Vasta viime aikoina olen oppinut uusia tapoja yksikkötestien kirjoittamiseen. Mutta miksi ihmeessä yksikkötestejä kirjoitetaan?

Miksi

1. Luotettavuus. Yksikkötesti on ainoa tapa varmistaa, että koodi tekee nyt ja tulevaisuudessa haluamani asiat. Jos minä tai joku muu muokkaa koodia, niin yksikkötestillä voi varmistaa, ettei vanha toiminnallisuus mene rikki.
2. Yksikkötestillä testaaminen käy nopeammin, jos testiä varten pitää sovellus saada tiettyyn tilaan. Testaajan sisäänkirjautuminen ja erilaisten testitapausten luominen vie hyvän tovin.
3. Parempilaatuinen koodi. Yksikkötestattava koodi on yksinkertaista. Yksikkötestejä kirjoittaessa jättimetodit ja monimutkaiset kokonaisuudet pikkoutuvat pienempiin osiin kuin itsestään. Muut kehittäjät lukevat tällaista koodia meilummin kuin 2000 rivin hirviömetodia, jossa on runsaasti if-lohkoja.
    
   Lisäksi muilta kuultua:

4. Vähentää koodista löytyviä virheitä (bugit).
5. Voi tehdä suuria muutoksia koodiin nopeasti.
6. Välitön palaute koodatessa. Tiedät heti koodisi toimivan, kun syttyy vihreä valo.
7. Testien avulla näkee miten metodin on tarkoitus toimia.
8. Testien avulla ymmärtää koodin rakenteen paremmin.
9. Yksikkötestin avulla pääsee helposti liikkeelle koodaamisessa, jos pitää luoda suurempi kokonaisuus.
10. Testien kirjoittaminen on hauskaa.

Se maksaa

Niin maksaa. Yksikkötestien kirjoittaminen vie hieman enemmän aikaa, mutta menetetty aika ja raha saadaan takaisin virheiden vähentyessä (luotettavuus), tuoteen laadun parantuessa (asiakastyytyväisyys), ylläpiettävyydessä (koodia voi muokata ja refaktoroida tai optimoida nopeammaksi) ja virheiden metsästyksen helpottuessa.

Yksikkötestattu koodi sisältää vielä virheitä. Kehittäjä joskus ymmärtää väärin ja kirjoittaa siksi viallista koodia tai unohtaa jonkin erikoistapauksen. Tällöin kirjataan vika. Kirjoitetaan yksikkötesti, jolla todetaan virheen toistuvan. Korjataan koodi. Vanhoista yksikkötesteistä näkee heti, ettei aiempi toiminnallisuus hajonnut. Käsin testattaessa prosessi olisi hitaampi, koska uudelleentestaus kestää.

Mitä ei kannata testata

Käyttöliittymän ulkoasun tai toimintojen yksikkötestaaminen on harvoin kannattavaa. Elementtien sijainti ja ulkoasu korjataan tyypillisesti kerran.

Jos sovellus käyttää omaa tietokantaa, datan oikeellisuutta ei tarvitse testata. Tallennan kantaan aina hyvälaatuista dataa. Mikäli data tulee ulkoisesta järjestelmästä, jonkun rajapinnan kautta, niin testaaminen voi olla perusteltua.

Tiedon oikeellisuus testataan korkeintaan kerran. Tyypillinen tilanne on testata käyttäjän antama syöte esimerkiksi sotu. Kun sosiaaliturvatunnus todetaan olevan oikeassa muodossa, sitä ei tarvitse myöhemmin tarkistaa. Vapaan tekstikentän sisällön tarkistaminen on järjetöntä. Käyttöliittymäkomponenteille voi antaa kentän maksimipituuden, jolloin vältytään turhilta tekstin pituustarkastuksilta.

Kaikkia tapauksia EI testata. Yksikkötesteihin kirjoitetaan joitain mahdollisia virhetapauksia, joilla voidaan varmiistaa metodin hyvä käytös virheellisellä syötteellä esim. null. Jos koodi laskee jotain, riittää todeta induktiivisesti, että se toimii. Siis tapauksessa 0, perusarvot. Tapauksessa yksi ja n+1. Yksikkötestin sisällä ei pitäisi koskaan olla for-silmukkaa.

Mitä seuraavaksi

Ota kehitysympäristö esille ja aloita yksikkötestien kirjoittaminen!

Katso myös

• Stackoverflow: Is unit testing wort the effort?
• O’reilly: Top 12 reasons to write unit tests
• Martin Fowler: Yksikkötestauksen hinnasta
• Selective Unit Testing – Costs and Benefits