niewolny.info … yet another .net blog.

26May/121

Silverlight & async unit testing

W pracy mamy aplikacje, która jest pisana w Silverligtcie. Ostatnio trafiła do mnie potrzeba napisania unit testa do pokrycia command'a z ViewModela. Niestety, sam command wykorzystuje pewne dane słownikowe, które wcześniej aplikacja sobie zaczytuje asynchronicznie z WCF'a.
W projektach, w których dotychczas uczestniczyłem asynchroniczność była wykorzystywana na niskim poziomie i w zasadzie, nigdy nie miałem przyjemności i okazji do napisania testu pod coś co łączy się w takim trybie. Dodatkowo dane słownikowe winny się były załadować na początku unit testu w metodzie inicjalizującej, ponieważ chciałem je móc wykorzystać w kilku testach.

Okazuje się, że można coś takiego zrobić o czym dość fajnie napisał norweski programista Jonas Follesø.
Testowanie to, generalnie opiera się o metody "EnqueueXXX", do których mamy dostęp jeśli nasza klasa podziedziczy sobie po SilverlighTest, a które sobie rejestrują co chcemy wykonać, a potem to wykonują.
Trochę to tak dziwnie wygląda, bo gdy mamy taką metodę:

 

... to gdy się przez nią przedebugujemy, to zauważymy, że najpierw wykona sobie części kodu na które debugger napotka, a następnie zacznie wywoływać sobie metody z części Enqueue.

I wszystko niby fajnie, ale jest kilka pewnych " ale "... :/

    • czytelność tych testów zaczyna być zdrowo zaburzona. Jeżeli nie napiszemy sobie komentarzy, to za jakiś czas może się okazać problemem zrozumienie na szybko "ale co ja właściwie chciałem tu zrobić" -.-'
    • wsparcie frameworka do testowania jest delikatnie mówiąc - mizerne, w przypadku gdy coś nie zadziała, to w zasadzie nie dostarczy nam żadnej konkretnej informacji, co poszło nie tak. Np. gdy zapomnimy sobie dodać dyskusyjne "EnqueueTestComplete()" nasza aplikacja sobie zastygnie, a my będziemy się głowić... co tu Panie nie działa?
    • EnqueueConditional mogłoby mieć opcję timeout'u. Na chwilę obecną niestety nie możemy powiedzieć naszemu testowi "ty tu sobie siedź i czekaj na isDone, ale jak nic się nie stanie przez 20 sek, to idź z koksem dalej".
      Przez co, gdy np, ktoś gdzieś sprawdzi paremetry wejściowe w taki sposób:

       
      ..., a nasz kod przechodzi przez właśnie taką metodę, to aplikacja sobie zawiśnie na metodzie EnqueueConditional, a naszym oczom ukaże się taki oto niewiele mówiący komunikat:

Comments (1) Trackbacks (0)
  1. ahhh… dumny jestem z Czesia piszacego Unit Testy 🙂 Jak za pare tygodni napiszesz posta w ktorym opisujesz jak zastosowales Test-Driven Development to masz u mnie piwo!


Leave a comment

No trackbacks yet.