70 likes | 257 Views
Automatinis testavimas . A r verta ?. 2013 G.Ki šonas. Automatiniai regresiniai testai. Situacija: jums duota u ž duotis senam projekte padaryti pakeitimą. Apart pačio projekto ir jo vartotojų, jokio žinių šaltinio nėra. Regresiniu testu nėra.
E N D
Automatinistestavimas.Ar verta? 2013 G.Kišonas
Automatiniai regresiniai testai Situacija: jums duota užduotis senam projekte padaryti pakeitimą. Apart pačio projekto ir jo vartotojų, jokio žinių šaltinio nėra. Regresiniu testu nėra. Yra keli regresiniai testai, dengiantys pagrindinius scenarijus. Yra šimtai regresinių testų. Verta atsiminti – regresinių testų palaikymas kainuoja daug, o visų galimų scenarijų visviena nepadengsite. Automatiniotestavimo principas nr. 1 – visadaturėkite automatinius regresinius testus dengiančių pagrindinius scenarijus ir nevenkite šalinti nebeaktualių regresinių testų. Regresinių testų tikslas - minimaliomis pastangomis parodyti, kad sistemos pagrindinės funkcijos veikia.
Pavyzdys iš Adform gyvenimo: Projektas „Adserving“ Brangiai kainavęs bandymas padengti regresiniais testais didžiaja dalį funkcionalumo buvo nutrauktas išėjus už tai buvusiam atsakingam asmeniui motinystės atostogų. Palikti keli aktualūs testai, patikrinantys pagrindinį funkcionalumą. Verta paminėti jog šį projektą netiesiogiai testuoja ir kiti regresiniai testai, testuojantys visą sistemą, plius atsiradus pasitikėjimui metrikomis, itin kruopščių regresinių testų poreikis atkrito.
Automatiniai modulių(unit) testai Situacija: susitvarkius su regresiniais testais pradedame daryti kodo pakeitimus. Kodas susideda iš kelių klasių monstrų. Yra daug klasių, bet jos persipynusios priklausomybėmis ir pakeitus ką nors reikia testuot viską. Kodas sudarytas iš šimtų mažyčių nepriklausomų klasių. Verta atsiminti – testuoti modulį (klasę) visada bus paprasčiau jei to modulio priklausomybės yra abstrakčios (interfeisai). Automatinio testavimo principas nr. 2 – modulių testuose testuokite tik konkretų modelį o ne susijusių modelių raizgalynę. Idealu jei kitų modulių ir duomenų naudojimas yra suabstraktintas naudojant mock‘us ir databuilder‘ius.
Pavyzdys iš Adform gyvenimo: publicclassReferrerTransformer : ITransformer<PreProcessTransaction> { privatereadonlyIReferrerParsingManager _referrerParsingManager; public ReferrerTransformer(IReferrerParsingManager referrerParsingManager) { _referrerParsingManager = referrerParsingManager; } public ReferrerTransformer(IMetadataManager metadataManager) : this(newReferrerParsingManager(metadataManager)) { } publicvoid Transform(PreProcessTransaction transaction) { transaction.UrlFromReferrer = _referrerParsingManager.ExtractReferrerData(transaction.UrlFrom); } } privatereadonlyITransformer<PreProcessTransaction> _transformer = newReferrerTransformer(newMetadataManager(DataHelper.SetupMockedMetadataDbFactoryWithData(), TimeSpan.MaxValue)); publicvoid Given_GoogleDk_ParsesCorrectly() { var transaction = newFixture() .Build<PreProcessTransaction>() .With(t => t.TransactionType, TransactionType.TrackingPoint) .With(t => t.UrlFrom, "http://www.google.dk/search?aq=0&oq=canaldig&sourceid=chrome&ie=UTF-8&q=canaldigital") .CreateAnonymous(); _transformer.Transform(transaction); Assert.That(transaction.UrlFromReferrer.Type, Is.EqualTo(ReferrerType.NaturalSearch)); Assert.That(transaction.UrlFromReferrer.Domain, Is.EqualTo("www.google.dk")); Assert.That(transaction.UrlFromReferrer.Keywords, Is.EqualTo("canaldigital")); }
Automatiniai kompleksiniai modulių(unit) testai ir testai paliečiantys infrastruktūrą Atskira tema – testai, kurie testuoja grupe modulių ar net kreipiasi į infrastruktūrą (log failus, duomenų bazę ar web servic‘us), tačiau nėra regresiniai, nes neaprėpia viso veiklos scenarijaus. Paprastai tokie testai rašomi programos kūrimo metu, nes tai paprasčiais būdas sužinoti ar viskas veikia kaip numatyta. Tačiau labai dažnu atveju tokie testai būna ir vieninteliai testai testuojantys kažkurį modulį. Dažnu atveju normalaus testo neišeina užrašyti dėl blogo kodo dizaino (per tampriai susije moduliai). Nereikia dėl to daryti tragedijos, tol kol testai veikia ir atlieka savo funkcija viskas gerai, tačiau siekite, jog modulių testai būtų kuo grynesni, t.y. butu testuojami tik moduliai, neliečiant infrastruktūros ir visa kita kuo labiau suabstraktinant. Tai pasiekiama nuolatinio refaktorinimo metu. Automatinio testavimo principas nr. 3– nenustokite refaktorinti ne tik kodo, bet ir testų.
Taigi Visadaturėkite automatinius regresinius testus dengiančių pagrindinius scenarijus ir nevenkite šalinti nebeaktualių regresinių testų. Regresinių testų tikslas - minimaliomis pastangomis parodyti, kad sistemos pagrindinės funkcijos veikia. Modulių testuose testuokite tik konkretų modelį o ne susijusių modelių raizgalynę. Idealu jei kitų modulių ir duomenų naudojimas yra suabstraktintas naudojant mock‘us ir databuilder‘ius. Nenustokite refaktorinti ne tik kodo, bet ir testų. Ačiū už dėmėsį. Klausimukai?