Biblioteka dostępu do TFS i testy jednostkowe
W poście Tfs Spotlight – buduję własny CAB wprowadzającym do mojego projektu TfsSpotlight wspomniałem, że
jednym z moich celów jest pisanie testów jednostkowych. Chcę w ten sposób
zobaczyć jakie problemy pojawią się podczas pisania testów jednostkowych dla
większego i bardziej skomplikowanego projektu niż te, które do tej pory
robiłem.
Proces pisania testów jednostkowych nie jest łatwy i co
jakiś czas napotykam pewne problemy. Ostatni problem pojawił mi się w momencie,
gdy chciałem napisać test dla klasy prezentera, który obsługuje widok
konkretnego workitema. Źródłem danych dla tego widoku jest obiekt klasy
pochodzącej z biblioteki dostępu do TFS – klasa WorkItem. Jak się szybko okazało
napisanie testu jest niemożliwe, jeżeli bierzemy przypadek całkowitego
odizolowania. Wszystko to dlatego, że nie mogę ręcznie utworzyć instancji tej
klasy. Do tego potrzebne jest połączenie z serwerem (sic!). Moje zamiary spełzły
na niczym. W dodatku klasa ta jest sealed, więc Rhino Mocks robie nie radzą. Nie
mam zielonego pojęcia jak sobie z tym poradzić.
Wracając do biblioteki TFS pozwalającej na dostęp do
serwera to należy zauważyć, że programiści i projektanci tego API zabezpieczyli
się przed nieumiejętnym jego wykorzystaniem, aby zapobiec nadmiernemu
obciążeniu serwera. Elementy takie jak Project, Query, WorkItem czy ich
kolekcje są zaimplementowane w postaci klas, które swoje dane ładują w sposób
leniwy. Tym sposobem wyświetlając w tabeli workitemy, pobierane są tylko
właściwości wyświetlane w kolumnach. Pozostałe nie zostaną ściągnięte. Takie
zachowanie na pewno ogranicza ilość danych przesyłanych z serwera, ale niestety
sposób wykonania tych elementów może pozostawiać wiele do życzenia. Wszystkie
te klasy o których mowa są sealed, a serwisy nie zostały opisane żadnymi
interfejsami definiującymi kontrakty. Wygląda na to, że w tym przypadku nie
pomyślano o Zasadzie oddzielenia zagadnień (ang. Separation of Concerns).
Podobnie jest z kontrolkami dostarczanymi w bibliotece TFS. Okazuje się, że
podpinając im źródło danych one i tak pytają o coś serwer (sic!)
Budując system luźno powiązany praca z takimi komponentami
jest bardzo uciążliwa, a w tym przypadku skutecznie uniemożliwia mi pisanie
testów. Chociaż trzeba zaznaczyć, że jest światełko w tunelu. Od jakiegoś czasu co raz częściej słyszy się o co raz to nowszych projektach ze stajni MS, które wspominają o testach jednostkowych. Ba, wczoraj Scott Guthrie ogłosił, że Silverlight 2 jest testowany przy pomocy testów jednostkowych (jest ich ponad 2000) i co więcej dostarczają również narzędzi do testowania własnych projektów Silverlight-owych. Bardzo mnie ten trend cieszy, gdyż może następna wersja biblioteki dostępu do TFS będzie ten trend uwzględniała.