‘Testimine’ sildiga artiklid
Halloo… testid on ka kood!
Mingil põhjusel arvatakse, et testid on samaväärsed write-only koodiga ning ei kanta erilist hoolt selle üle, et neid tulevikus hallata saaks. Küllaltki kurb on tõdeda pärast ümberstruktureerimist katkiseid teste, millest pole võimalik väga aru saada.
Pakun välja mõned võimalused testide paremaks struktureerimiseks.
Esimest varianti on võimalik kasutada küllaltki lihtsalt olemasolevate testide peal. Kuna testid koosnevad kolemast osast (Arrange, Act, Assert; Given, When, Then), siis võib testi ka selliselt tükkideks jagada. Cucumberi kasutajatele peaks see olema küllaltki tuttav: samalaadselt tuleb kirjeldada ära sammud. Selle pahupooleks võibki sammude haldamine olla, sest test on tükeldatud, kuid ülevaate saab palju kiiremini ning on korduvkasutatav.
1926. aastal ilmus Henry Fordi kirjutatud raamat “Täna ja homme”, mis andis edasi autori mõtteid muuhulgas Fordi tehaste töökorraldusest. Soovitan kindlasti lugeda, kuna tegemist on ka Toyota Production System-i ja Lean-i ja kaudselt ka igasuguste väledate arendusmetoodikate alusega. Tõsi, üllatusin ka ise, et masstootmise looja kirjutab raiskamise vältimisest.
Igal juhul tahtsin välja tuua ühe lõigu selle kohta, kuidas Fordi tootmises Ford-T nukkvõlli kaheksa nuki ajastust automaatselt testiti. Loe edasi »
Testide koodihulk küündib hea kaetavuse korral küllaltki lähedale toote enda omaga. Vahel võib seda isegi rohkem olla. Projektide puhul üritame hallata koodi võimalikult hästi, kuid testid tunduvad esialgu sekundaarsed ning seal kasutatakse praktikaid, mida toote koodis välditakse viimse võimaluseni.
Komponenditestid (unit test) on igati head, kui neist saab välja lugeda, kuidas API-t või süsteemi kasutada ehk need käituksid dokumentatsioonina. Siiski selle saavutamine ei pruugi olla eriti lihtne, kui neist ei hoolita. Testid ei ole “Write Only” kood.
Gerard Meszaros on teinud suure töö ja kirjutanud paksu raamatu “xUnit Test Patterns: Refactoring Test Code”, kus seletab milliseid mustreid testimisel kasutada. Lisaks saab selle abiga treenida enda nina testimisel tekkivate haisude tundmiseks.
Raamat on jagatud kolme ossa: üldiselt testimisest (peamiselt xUnit raamistikkude kasutamise osas); testide haisud; testide mustrid. Esimesed kaks osa võiksid läbi lugeda ka projektijuhid, et nad teaksid, mis kasu automaatsetest testidest saab ning ei hakkaks ajama juttu, et testid pole olulised. Teise osa kohta saavad nad peamiselt teadmisi, millal piim hapuks läheb ning kuidas võiks reageerida. Arendajatel tuleks lugeda ka kolmas osa läbi. Algul on üldisemad mustrid, mis ei pruugi testimisega tegevale arendajale väga suur huvi pakkuda, kuid lõpu poole tuleb veidi keerulisemat ka.
Tarkvara arendajad võiksid selle teose enda lugemis nimekirja küll võtta. Vähemalt need, kes tahavad oma tööstiili stressivabamaks teha.
TechEd 2008 sai külastatud ka Roy Osherove‘i ettekannet teemal “Understanding Why You Need Test Driven Development and More“, mis oli “TDD by Example“. Selle juures mu jaoks kõige huvitavam oli, mida on võimalik TDD all silmas pidada. Ilmselgelt tuleb endale see kõigepealt selgeks teha, sest ilma selleta on kuidagi väär öelda, et teen TDD. Loe edasi »
Mõnda aega olen kasutanud Java platvormilt ületoodud .NET raamitikule ORM-i NHibernate. Praegu on saadaval versioonid 1.2 ja 2.0. Selle kasutamisega juhtub mingi hetk see, et ADO.NET-i peale ei tahakski tagasi minna (Siis peab ise andmekihti kirjutama hakkama ja mudeli kasutamine oleks tunduvalt raskendatud).
Kuna NHibernate on küllaltki suur ning seda niisama lihtsalt kiirelt selgeks ei tee. Õnneks on Stephen A. Bohlen teinud õppevideote seeria: Summer of NHibernate. Nendest on suur abi algajale ja ka vanad koerad võivad uusi trikke õppida. Loe edasi »
Vahel tüütab ära siluri kasutamisel, et käiakse läbi meetodeid, mis ei väga informatiivsed. Näiteks get ja set meetodid (property). Mõnikord ka vähe tegusam meetod või klass.
Võimalusi on mitmeid, võime pidevalt kasutada StepOver funktsiooni, kuid see alati ei aita. Vaatame korra järgnevat klassi. Loe edasi »
Mõni aeg tagasi loodi uus võltsitud objektide raamistik .NET platvormile nimega Moq, mida peaks hääldama “Mock-you” või “Mock”. Selle peamiseks leivanumbriks väidetavalt on API lihtsus. Ilunumbriks võrreldes teiste raamistikkudega on C# 3.0 võimaluste kasutamine, peamiselt lambda süntaks ning .NET 3.5 platvormi võimaluste kasutamine.
Vaadates esmaseid näited sellega, siis tundub see tõesti suhteliselt lihtne võrreldes siiani ühe parima raamistiku Rhino Mocks‘iga. Siiski pole kõik alati nii ilus kui algselt reklaamitakse.
Inimestel on kalduvus hoiduda ohtlikest asjadest. Keegi ei soovi kasutada midagi sellist, mis seab ohtu nende elu. Süsteemide, mille käitumist, ei saa prognoosida, ei saa pidada piisavalt usaldusväärseks, et kasutada seda koduses majapidamises ega ka ärilises tegevuses. Selleks, et parandada olukorda, on võetud kasutusele testimismeetodid.
Testimine tähendab üldisemalt käitumise kontrollimist eeldustele. See ei tähenda, et testid peaksid lõppema alati ei-jah vastusega, vaid võivad anda andmeid, mida tuleb edasi töödelda.
Ei ole mõttekas soetada endale autot, mis ei läbi turvalisuse või funktsionaalisuse teste. Kõik peab töötama laitmatult, et saaks nautida ilusat sõitu. Vaadeldes seda tarkvara seisukohalt, siis ei tahaks, et see toimiks ettearvamatult. Arve peal olev maksumus peaks vastama soovitule, mitte olema juhuslik arv.
Selle kandes vaatleme kõige väiksema skoobiga teste ja tehnikaid nende loomiseks. Loe edasi »
Testide kirjutamine ei ole keerukas (juhul kui väga jubedat koodibaasi all pole), kuid neid võib loogika tõttu palju tulla. Seega on probleemiks testimata koodi leidmine, kuigi see mure on pikemat aega lahendatud koodikaetavuse auannetega.
Esmalt vaatame, mis koodikaetavus on. Seda võib defineerida testides käivitatud koodiridadena s.t need koodiread on testide poolt käivitatud. Loe edasi »
KAIZEN FEED
Telli endale Kaizeni uudisvoog
KOMMENTAARIDE FEED
Telli endale kommentaaride voog
KAIZEN TWITTER
Lühiuudised Kaizeni autoritelt
KAIZEN FACEBOOK
Liitu Kaizeniga
MIS ON KAIZEN?
Kaizen on Saiku tarkvaraarendusealane blogi, kus kirjutame erinevatest lähenemistest meisterlikule tarkvaraarendusele.
KATEGOORIAD
- .NET (18)
- Analüüs/Arhitektuur (11)
- Arendus (66)
- Ettevalmistus (1)
- Juhtimine (2)
- Varia (23)
SILDIPILV
- .NET (41)
- ilus kood (23)
- Arendus (23)
- C# (20)
- Analüüs/Arhitektuur (14)
- Testimine (10)
- raamat (8)
- Ruby (8)
- projektijuhtimine (8)
- printsiibid (6)
- produktiivsus (5)
- ReSharper (5)
- PHP (5)
- NHibernate (4)
- objekt-orienteeritud (4)
- pidev integratsioon (4)
- Viited (4)
- agile (4)
- Java (4)
- Geekdinner (4)
- lean (4)
- raamatukogu (4)
- CI (3)
- Cruise Control.NET (3)
- Robert C. Martin (3)
- scrum (3)
- iteratsioon (3)
- suhtlus (3)
- jQuery (2)
- TechEd 2008 (2)
- Visual Studio (2)
- valideerimine (2)
- intervjuu (2)
- analüüs (1)
- ASP.NET (1)
- ümberstruktureerimine (1)
- üritus (1)
- CodeRush (1)
- dokumentatsioon (1)
- Kent Beck (1)
- LINQ (1)
- Martin Fowler (1)
- Moq (1)
- Rhino Mocks (1)
- stackoverflow (1)
- võltsitud objektid (1)
- Whiteboard Wednesday (1)
- hindamine (1)
- tarkvara kvaliteet (1)
- ajagraafikud (1)
- Saiku (1)
- koolitus (1)
- tagasivaate (1)
- koosolek (1)
- dünaamilised keeled (1)
- staatilised keeled (1)
- FluentNHibernate (1)
- facebook (1)
- aastapäev (1)
- Rake (1)
- Oredev 2008 (1)
- toyota way (1)
- raiskamine (1)
- NDepend (1)
- podcasts (1)
- väle tarkvaraarendus (1)
- raido tonts (1)
- minimal marketable feature (1)
- kasutajalugu (1)
- twitter (1)
- Joomla! (1)
- MVC (1)
- andmebaas (1)
- versioonimine (1)
- diskussioon (1)
- regulaaravaldised (1)
- motiveerimine (1)
- mõõdikud (1)
- agileestonia (1)
- riistvara (1)
- koolitused (1)
- kujundus (1)
- kodulehed (1)
- veeb (1)
