Testide haldamine

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.

Testimisega alustades luuakse üks projekt, kuhu hakatakse teste kirjutama. Kuna üks projekt on ilmselgelt vähe, siis tekkib seal kompott komponendi-, integratsiooni- ja vastuvõtu testidest. Selle vältimiseks tasuks luua iga liigi jaoks eraldi projekt. Kuna integratsiooni- ja vastuvõtu testid on aeglasemad, siis nende pidev jooksutamine on ajakulukas ning võib pärssida testimist. Seevastu komponenditeste tuleks väga tihedalt jooksutada. Lisaks neile olen teinud ka projekti õppimiseks, näiteks Arc.Learning.Tests kuhu alla panen katsed kuidas mingeid asju lahendada. Neid ei peaks iseenesest üldse jooksutama, kuid neis leidub ka oma väärtus – raamistike muutumisel võib olla see märgutuleks.

Testimise projekte tuleb umbes 3-4 tükki kokku. See annab märku, et iga toote projekti kohta ei tasuks luua komplekti testprojekte, vaid kasutada neid terve lahenduse jaoks.

Arc.Domain, Arc.Infrastructure, Arc.Infrastructure.Dependencies.Structuremap, Arc.Infrastructure.Dependencies.CastleWindsor… – igaühe jaoks testide projektide komplekt tähendaks üle 16 projekti ja see ei oleks enam hallatav. Lisaks mõned projektid sisaldaksid ainult paari testi.

Viimasel ajal olen veel täheldanud, et võltsitud objektide osa hakkab erinevates testide projektides korduma ning mõistlik oleks ka need eraldi projekti alla viia.

Visual Studio soovitab projektide loomisel lahenduse peakausta salvestamiseks. Siiski mõistlik tegevus on jagada need erinevatesse kataloogidesse: Source ja Tests. Sel puhul on build skripte veidi lihtsam kirjutada.

Testide projektide nimetuse osas olen kahe variandini jõudnud: Solution.Unit.Tests või Solution.Tests.Unit. Esimene neist tundub veidi loetavam ja kui nad on eraldi kausta salvestatud, siis ei ole järjekorra osas ka vahet.

Testide enese haldamiseks on järjekordselt kaks mõistlikku lähenemist: testid klassi kohta, testid spsteemi funktsionaalsuse kohta. Viimane neist viitab kontekstide poole, mis on BDD pärusmaa. Vastavalt variandist võiks klasside nimed lõppeda Tests või Specs.

Siinkohal on minu poolsed soovitused lõppenud ja jään ootama teie poolseid lahendusi, kuidas testidest paremini jõud üle käiks. Meeldivat testimist!