Ukazał się kolejny artykuł z cyklu Azure. Tym razem opisałem połączenia hybrydowe zrealizowane za pomocą ServiceBus:
http://msdn.microsoft.com/pl-pl/library/windows-azure-appfabric–polaczenia-bezposrednie
Ukazał się kolejny artykuł z cyklu Azure. Tym razem opisałem połączenia hybrydowe zrealizowane za pomocą ServiceBus:
http://msdn.microsoft.com/pl-pl/library/windows-azure-appfabric–polaczenia-bezposrednie
Kolejny artykuł. Tym razem o uwierzytelnianiu za pomocą zewnętrznych dostawców (Google, Yahoo itp):
http://msdn.microsoft.com/pl-pl/library/azure-appfabric-i-access-control-service
W poprzednim poście pisałem ogólnie o testach integracyjnych. Dzisiaj zajmiemy się pierwszym podejściem – top-down.
W podejściu top-down najpierw wykonywane są testy punktów wejściowych (entry point) a następnie tester doczepia stopniowo kolejne moduły. Punktem wejściowym dla poniższego systemu jest węzeł M1. Testowanie M1 odbywa się na zasadzie testu jednostkowego. Z tego względu M2 oraz M6 muszą być zastąpione obiektami mock. Kolejnym etapem jest przetestowanie węzła M2. W tym przypadku M3 i M5 muszą być zamienione na obiekty mock. Ostatnim etapem w podejściu jest przetestowanie całego systemu bez obiektów mock. Bardzo ważne jest aby nie testować od razu całości a jedynie pojedyncze węzły. Wszelkie połączenia należy zastępować zatem prostymi mock’ami. Dzięki temu, w przypadku błędów tester wie, które miejsca podejrzane są o wystąpienie tego problemu. Rozszerzając system stopniowo (zastępując mock’i prawdziwymi obiektami) jest pewne, że ewentualne błędy znajdują się w ostatnio doczepionym węźle.
Etapy testów:
Zaprezentowane wyżej podejście, jest tzw. integracją wszerz. Można również wykonać integrację w głąb przechodząc kolejno przez M1, M2, M3, M4, M5, M6, M7. Wybór metody zależy od struktury modułów w systemie jednak nie ma to większego znaczenia ponieważ oba sposoby należą do testów typu top-down i mają tą samą wadę – obowiązek tworzenia obiektów mock. Zaletą podejścia top-down jest fakt, że nie trzeba tworzyć sterowników testu (kodu, który wywołuje odpowiednie moduły). Rolę sterownika odgrywa rzeczywisty moduł. Przykładowo, sterownikiem w etapie pierwszym, na powyższych rysunkach jest moduł M1.
Orchard jest systemem CMS napisanym w ASP.NET MVC 3.0. Zachęcam do lektury!
http://msdn.microsoft.com/pl-pl/library/orchard-cms–wprowadzenie
Dla tych, którzy mają wątpliwości jak rozliczany jest Azure ( i w jaki sposób można za niego bezpiecznie płacić) polecam artykuł:
http://msdn.microsoft.com/pl-pl/library/platnosci-windows-azure
Zachęcam do przeczytania kolejnego artykułu z cyklu Azure:
http://msdn.microsoft.com/pl-pl/library/multicasting-w-azure-appfabric
Testy jednostkowe testują wyłącznie lokalne wykonywanie metod i jest nawet niewskazane aby testowane metody odnosiły się do zewnętrznych, zdalnych zasobów.Rozbudowane systemy są często rozproszone, działające na wielu komputerach oraz składających się z wielu modułów. Podstawowe pytanie brzmi: Jak sprawdzić czy utworzone moduły współpracują ze sobą? Otóż należy przeprowadzić testy integracyjne zgodnie z wybraną metodyką.
Testy integracyjne tak jak testy funkcjonalne powinny być przeprowadzane na bieżąco. Nie powinno czekać się z testami integracyjnymi aż do momentu kiedy wszystkie moduły będą ukończone – wtedy ciężej zlokalizować połączenia oraz na wszelkie zmiany architektoniczne może być już za późno.
Po walidacji logiki zawartej w pojedynczych modułach przychodzi czas na sprawdzenie połączeń między pakietami. Wykonanie testów integracyjnych może nastąpić wyłącznie po prawidłowej weryfikacji kodu przez testy jednostkowe. Jeśli występuje błąd na poziomie metod (testy jednostkowe), tym bardziej będzie występował na poziomie całych pakietów.
Przed rozpoczęciem jakichkolwiek testów integracyjnych należy zidentyfikować wszelkie połączenia między modułami. Powyższy diagram przedstawia fikcyjny system – grupę modułów z odpowiednimi relacjami.Przez moduł rozumie się zarówno klasę jak i bibliotekę. Stopień przyjętego rozdrobnienia zależy od testera. Z praktyki wynika, że należy przyjąć kryterium logiczne czyli podzielić system na pewne fragmenty funkcjonalne. Czasami testowanie pojedynczych klas nie ma sensu ponieważ są one zbyt mało skomplikowane i prawdopodobieństwo wystąpienia błędu związanego z integracją jest niskie.
W testach integracyjnych wykorzystuje się obiekty Mock. Skuteczność zależy niestety w dużej mierze od architektury systemu. Jeśli wykorzystywaliśmy IoC będzie nam dużo łatwiej testować system poprzez odłączanie kolejnych modułów. Istnieje kilka podejść do testowania – ale o tym w następnych poście!
Dziś trochę czystej teorii dla tych, którzy potrzebują wywoływać komponenty COM. W Internecie znajduje się wiele artykułów o różnicach między STA a MTA. Większość jednak opisuje je dosyć szczegółowo uwzględniając wiele aspektów technicznych i przez to nie zawsze może być to zrozumiałe. Podstawy jednak są bardzo proste i w poście skupie się wyłącznie na nich – szczegóły z pewnością znajdziecie na MSDN.
Przede wszystkim STA, MTA mają znaczenie wyłącznie gdy korzystamy z obiektów COM. To pozostałość po dawnych czasach. Na początku istnienia COM, nie było wielowątkowości i programiści nie musieli martwić się o synchronizację, sekcje krytyczne, semafory, muteksy, deadlock, livelock, zagłodzenie itp… Tworzone biblioteki nie wspierały więc wielowątkowości ponieważ takowa wtedy nie istniała. Problem pojawił się jednak gdy na rynku zaczęły pojawiać się pierwsze programy wielowątkowe. Wiadomo, że te stare biblioteki nadal będą musiały być wykorzystywane. Wprowadzono więc tzw. dwa modele STA oraz MTA.
Dla starych bibliotek używamy STA. W modelu przyjmuje się, że kod COM możemy być jednocześnie wywoływany z jednego wątku – co likwiduje nam problemy z synchronizacją itp. Jeśli zdarzy się, że 2 osobne wątki będą chciały wywołać dany kod, wtedy wywołania są szeregowane w kolejce (Windows Message Pump).
Z kolei w MTA dopuszcza się wywoływanie jednoczesne z różnych wątków. Biblioteki MTA muszę zatem być napisane w sposób “thread-safe”, czyli uwzględniającym wielowątkowość. Trudniejsze wyzwanie ale bardziej wydajne.
Wszystkie aplikacje WPF, WinForms wykorzystują biblioteki COM STA stąd ich wątek główny najczęściej oznaczony jest atrybutem STAThreadAttribute .
Kolejny artykuł. Tym razem o AppFabric:
http://msdn.microsoft.com/pl-pl/library/azure-appfabric–wprowadzenie