Problem: Walidacja formularzy (rnego przeznaczenia - zarwno dane osobowe jak i opcje konfiguracyjne) w aplikacji GWT.

Oryginalnie rozwizanie polegao na tym, e kady Presenter formularza zawiera cakiem obszern funkcj validate(), w ktrej informacja o poprawnoci wdrowaa w zmiennej logicznej przez kilkanacie blokw kodu sprawdzajcych poszczeglne pola. Kady formularz mia osobno napisan funkcj sprawdzajc, co powodowao m.in: duplikacj - kod sprawdzajcy by kopiowany wszdzie tam, gdzie by potrzebny niedeterminizm - implementacje tego samego warunku pisane przez rne osoby rniy si znaczeniowo. Na przykad w jednym formularzu pole oznaczone jako wymagane akceptowao zawarto skadajc si z samych spacji, a w innym nie Rozwizanie: Obiektowy, modularny system walidatorw, ktry w prosty sposb pozwala budowa zestawy regu poprawnoci pl i zestawia je z odpowiednimi obiektami interfejsu uytkownika. Sprawdzanie formularza ma si ograniczy do wywoania funkcji isValid() na obiekcie typu FormValidator, w ktrym zostaa wczeniej zawarta struktura formularza. Najmniejszym klockiem w hierarchii jest interfejs Rule z metod isValid(String). Aby stworzy wasn regu naley napisa klas, ktra implementuje interfejs Rule - funkcja isValid zwraca true wtw podany String spenia warunki tej reguy. Przykad - klasa RuleNotEmpty, ktra odrzuca Stringi o dugoci 0 bd skadajce si z samych biaych znakw. Obiekty typu Rule implementuj moliwie atomowe reguy. Skadanie kilku regu w jedn umoliwia klasa ComplexRule. Przykad - klasa RulePesel to ComplexRule, ktra zawiera m.in. reguy RulePeselChecksum, sprawdzajc sum kontroln peselu i RulePeselDate, ktra sprawdzajc czy pocztkowe znaki peselu tworz poprawn dat. Kiedy ju mamy gotowe warunki moemy je przypisa do konkretnych pl formularza w obiekcie klasy FieldValidator (powstaj pary regua-pole). Nastpnie przekazujemy wszystkie zbudowane FieldValidatory do obiektu FormValidator, aby utworzy kocowy sprawdzalny formularz. Sprawdzanie odbywa si nastepujco: FormValidator iteruje po wszystkich FieldValidatorach i sprawdza, czy przypisane im pola maj zawarto zgodn ze wszystkimi swoimi reguami. Zalety: reguy wielokrotnego uytku znaczenie poszczeglnych zasad poprawnoci s spjne w caym projekcie budowanie walidatorw formularzy jest szybkie i zajmuje niewiele kodu, dziki czemu atwo zobaczy jakie reguy s przypisane konkretnym polom

TDD - wraenia

Przede wszystkim praktyki TDD sprawdziy si jako system wczesnego ostrzegania o niewygodnym API. Implementowane klasy tworz pewnego rodzaju biblioteczk obiektw pomocniczych - ich przeznaczenie to wielokrotne uywanie w wielu miejscach projektu, wane jest, aby udostpniane publiczne API byo wygodne, a udostpniane funkcjonalnoci miay moliwie du si wyrazu. W TDD piszc testy przed implementacj moemy uy naszych obiektw i szybko zorientowa si, e nasz projekt nie jest do koca uyteczny. Kiedy musiaem napisa fragment kodu rozwizujcy jak realn sytuacj, natychmiast pojawiy si pomysy na ulepszenia, ktre przeoczyem w trakcie projektowania na kartce. W takiej sytuacji miaem pen swobod poprawiania interfejsu, bo adne klasy nie zostay jeszcze zaimplementowane. Mj projekt skada si z trzech wyranych warstw: FormValidatora, FieldValidatora i Rulek. Dziki mockom kada z tych warstw bya implementowana odrbnie, mona byo skupi si wycznie na wymaganiach dotyczcych aktualnej warstwy, a bdy implementacji warstw niszych nie miay wpywu na poprawno reszty kodu. Musz przyzna, e mockowao mi si wyjtkowo wdzicznie - korzystanie z klas typu FailingRule/AcceptingRule, ktre zawsze zwracay false/true byo bardzo wygodne. Dodatkowo, mocki umoliwiy oddzielenie si od obiektw interfejsu uytkownika. Mj FieldValidator zamiast zwykego TextBoxa, trzyma obiekt interfejsu HasText - to interfejs posiadajcy tylko jedn metod - getText(). Ciko o lepszy interfejs do mockowania, a dziki temu skupiamy si tylko na aspektach, kre nas interesuj - w tym wypadku zawartoci pola. W GWT jest to szczeglnie wane, bo prawdziwe obiekty GUI wymagaj skomplikowanego (a przez to rwnie i powolnego) rodowiska uruchomieniowego. W moim przypadku wystarczyy zwyke testy JUnitowe korzystajce wycznie z POJO. To, co dao sie we znaki to objto testw i czas potrzebny na ich napisanie. W wypadku prostych klas typu RuleNotEmpty testy byy czasem 5 razy dusze ni testowana klasa. Niemniej jednak, przydaway si nawet w najprostszych przypadkach - czasem trzeba byo wyapa zgubiony ! przy zwracanej zmiennej logicznej w dwulinijkowej klasie. Na koniec memento: testuj swoje testy. Na pewnym etapie napisaem klas pomocnicz, ktra budowaa kolekcje mockw do testw. Tylko dziki przypadkowi zauwayem w niej bd, ktry zrobiem w metodzie pozostawionej na przyszo. Chwilowo adne testy z niej nie korzystay, wic nic si nie psuo, ale debugowanie po ewentualnie prbie uycia mogo by bardzo uciliwe.