Arkkitehtuurin suunnittelusta

Testiautomaatio järjestelmän arkkitehtuurin suunnitteluun siis kannattaa käyttää riittävästi aikaa. Alussa käytetty aika maksaa itsenä moninkertaisena takaisin jatkossa sujuvana ja tuloksellisena Testiautomaationa.
Mitä moniulotteisempi testattava applikaatio on (alivalikkoja joiden alla alivalikkoja jne..) sitä herkemmin systeemistä tulee niin himmelimäinen, että sen ylläpito ja jatkokehitys alkavat tökkiä jo alkuunsa.

Arkkitehtuuri malleja on varmaan niin monta kuin on suunnittelijaakin, mutta kaikissa hyvissä arkkitehtuureissa pätevät kuitenkin tietyt lainalaisuudet.
Usein helpointa on suunnitella kompleksisemmassa kohteessa ensin testattavan applikaation navikointi rakenteet.
Kun saa mielestään kohtuullisen selkeät ja toimivat navikointi mekanismit, niin silloin ei ainakaan vielä ole lähdetty vika suuntaan ja samalla on helpompi hahmottaa ylätasolla koko systeemin arkkitehtuuria.
Navikoinnissa, kuten muissakin yleisissä toiminnoissa, kannattaa toiminnot keskittää omaan moduuliin.

Yhteen kuvaan on vaikea saada kuvattua edes jotenki selventävästi ylätason laajempaa rakennetta, mutta yritän tässä kuitenkin.
Alla on yksi mahdollinen esimerkki Testiautomaation rakenteesta, joka voisi olla perustana, kun testattava applikaatio on iso ja moniulotteinen (paljon valikkoja ja alavalikkoja).
Tuossa toiminnot lohkottu kolmeen erilliseen lohkoon ja lisäksi erilliseen yleiseen kirjasto lohkoon.
Step koodi lohkossa on jokainen taso omassa ns. package osiossa, eli package osia tulee alekkain niin monta kuin on tasojakin. Package osioiden nimeämisessä, kuin myös luokkien ja rutiinien nimeämisessä kannatta käyttää formaattia, jossa suoraan nimestä voi jo päätellä mihin kohtaa testattavan applikaation näkymäavaruutta se kuuluu.