Ohjelmiston rakentaminen on monimutkainen prosessi. Erilaisten työkalujen ja ohjelmointikielten hallitsemisen lisäksi on myös ymmärrettävä erilaisia ohjelmistokehittäjän rooleja. Kuten useimmat meistä tietävät, loistavat projektit eivät sisällä vain koodausta. Suurissa projekteissa käytetään myös muita resursseja vaatimusten keräämiseen, prototyyppien luomiseen ja testaamiseen.
Koodin validointiprosessia kutsutaan usein laadunvarmistukseksi. Ilmaisu on kuitenkin hieman harhaanjohtava. Koodin laadun varmistamisen sijaan todellinen tavoite on sen mittaaminen – usein projektin edetessä. Tämä hienovarainen ero, joka tunnetaan myös nimellä testivetoinen kehitys (esim. TDD), voidaan havaita, kun tarkastellaan laatutoiminnon rooleja. Näitä ovat muun muassa seuraavat:
MIKSI YKSITYISKOHTAISET TESTAUKSET?
Kuten nähdään, laadun mittaaminen ryhmitellään usein automatisoituihin ja manuaalisiin toimintoihin. Kun joku on kiinnostunut algoritmeista, yksikkötesteiksi kutsuttu lisäkoodi toimii ensisijaisen ohjelmistoprojektin testaamiseksi. Yksikkötestit ovat yleensä kehittäjien kirjoittamia, ja niihin keskitytään TDD-ympäristössä. Esimerkiksi tämän kirjan kehittämisessä yksikkötestit ovat olennaisia. Käyttämällä iOS:n XCTest-kehystä käydään läpi, miten yksikkötestaus toimii Swiftissä.
TYÖSKENTELY XCTESTIN KANSSA
Jos olet perehtynyt kirjassa läpikäytyihin Swift-käsitteisiin, yksikkötestien kirjoittamisen opettelemisen pitäisi olla suoraviivaista. Kuten käsiteltiin, yksikkötestit toimivat harjoitellakseen koodia, josta puuttuu loppukäyttäjän käyttöliittymä. Esimerkkinä tarkastellaan testitapauksia, jotka harjoittavat Stack-tietorakennetta.
Kirjassa ei käydä läpi Xcoden integroidun kehitysympäristön (Integrated Development Environment, IDE) erityispiirteitä, mutta on syytä huomata, että testit voidaan suorittaa funktion, luokan tai kohteen mukaan. Xcoden avulla yksikkötestit perustetaan lisäämällä uusi testikohde pääkoodiprojektiin. Kun yksikkötestit on määritetty, ne voidaan suorittaa IDE:stä tai komentoriviltä.
TESTISÄÄNNÖT
Ei ole pakollista, mutta parhaana käytäntönä pidetään sitä, että yksikkötestitiedosto vastaa pitkälti toteutustiedostomme (-tiedostojemme) nimeämiskäytäntöä. Meidän tapauksessamme käytämme tiedostoa StackTest.swift. Jotta pääsemme käsiksi pääprojektimme ensisijaisiin Stack-metodeihin ja -ominaisuuksiin, tiedosto sisältää myös testattavan import-lausekkeen:
Kuten muutkin yksikkötestauskehykset, XCTest toimii integroimalla Swift-kielen ominaisuuksia tiettyihin testaukseen liittyviin toimintoihin. Olennaiset metodit on ryhmitelty väitteiksi. Testejä luotaessa kääntäjä tunnistaa yksikkötestit funktioista, joiden etuliitteenä on test-avainsana.
Toisin kuin tavalliset Swift-funktiot, yksikkötestit on tarkoituksella suunniteltu itsenäisiksi logiikan yksiköiksi. Tämän seurauksena testimenetelmät eivät hyväksy argumentteja eivätkä palauta arvoja. Vaihtoehtoisesti testidataa voidaan hallita apumetodien ja alustus-/purkusekvenssien avulla. Tarkastellaan seuraavaa:
TESTIEN SUUNNITTELU
Kuten käsiteltiin, pino-tietorakenteen tärkein toiminto on kohteiden lisääminen ja poistaminen. Sen sijaan, että kirjoittaisimme yhden funktion kaikkien operaatioiden testaamiseksi, testisuunnitelmamme eristää jokaisen tärkeimmän Stack-operaation omalla testillään. Kuten testPushStackin kohdalla nähdään, väite XCTAssertTrue tarkistaa Stack.count-muuttujan oikean alustuksen. Seuraavassa vaiheessa harjoitetaan Stack.push -muuttujaa iteroimalla numberList-olioiden joukko läpi. Varmistaaksemme, että jokainen testi käyttää samoja tietoja, numberList täytetään XCTestCase-luokan setup-metodin avulla.
Kun yksikkötesti Stackin kohteiden lisäämiseksi on toteutettu, voimme kirjoittaa seuraavan testin kohteiden poistamiseksi: