Na blogu oraz MSDN pisałem niejednokrotnie o testach jednostkowych oraz integracyjnych. Ostatnio jednak zastanawiałem się nad podstawowym problemem – jak zorganizować to od strony struktury katalogowej? Musimy rozważyć następujące problemy:Testy powinny być w każdej chwili dostępnie do odpalenia i weryfikacji.Wykonując prostą refaktoryzację (zmiana nazwy klasy), automatycznie nazwa powinna zaktualizować się w testach.Testy jednostkowe stanowią dobrą dokumentację oraz instrukcję używania zaimplementowanej...

autor: Wożę się z tym tematem od nie wiem już kiedy i niejednokrotnie pisałem, że coś takiego zamierzam. Teraz akurat nadszedł taki okres, że mam czas na trochę więcej pisania, więc się mobilizuję i rozpoczynam wreszcie swój blogowy minicykl o testach (głównie jednostkowych) na platformę .NET. O testach napisałem już sporo notek... pora na więcej:). Od wielu miesięcy spisywałem kluczowe pojęcia i myśli, jakie mnie nachodziły podczas programowania i testowania. Kilka tygodni temu zebrałem to wszystko w k...

http://msdn.microsoft.com/pl-pl/library/testy-obciazenia-w-visual-studio

Pisać testy jednostkowe do wszystkiego? Celować w 100% unit-test-code-coverage? Stosować TDD dla każdego rodzaju kodu? Na te pytania bardzo łatwo znaleźć w internecie odpowiedź i brzmi ona: TAK. Niestety nie jest to odpowiedź prawidłowa. Czasem lepiej testu nie napisać, niż go napisać. Czasem lepiej test skasować, niż go po raz dziesiąty poprawiać po zmianie w kodzie.

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...

Autor: Jakiś czas temu pisałem o TDD czyli o test driven development. Dzisiaj napiszę po co w ogóle bawić się w takie bezsensowne nadmiarowe rzeczy. Wikipedia definiuje to zagadnienie dosyć enigmatycznie: Test-driven development (TDD) jest techniką tworzenia oprogramowania zaliczaną do metodyk zwinnych (Agile). Pierwotnie była częścią programowania ekstremalnego (ang. extreme programming), lecz obecnie stanowi samodzielną technikę. Polega na wielokrotnym powtarzaniu kilku kroków:Najpierw programista pisz...

Testy jednostkowe to proste testy pozwalające na sprawdzanie działania aplikacji na poziomie klas i metod. Ich celem jest wspomaganie pracy programisty. Testów jednostkowych nie należy traktować jak testów aplikacji, które należą do zupełnie innej kategorii. Ciekawą koncepcją jest TDD czyli test driven development. Wg. niej najpierw tworzone zostają testy aby dopiero później stworzyć kod. Dzięki takiemu podejściu zmuszamy umysł do przemyślenia kodu zanim ten zostanie stworzony. Największa moc drzemiąca ...

Autor: Jakiś czas temu przeprosiłem się z frameworkiem MsTest i zacząłem na powrót pisać testy z jego wykorzystaniem. Przedtem korzystałem z NUnit, jednak doszedłem do wniosku, że do moich potrzeb wystarczy framework dostarczony w komplecie z Visual Studio. Nie jestem zealotem jeżeli chodzi o testy jednostkowe, piszę proste, wybiórcze testy, którymi na pewno nie pokrywam 100% kodu. Czytałem na kilku stronach narzekania na framework MsTest. Jednak podchodziłem do nich dość sceptycznie. Wiadomo, pro...

Mityczne 100% pokrycia W środowisku deweloperskim wciąż żywy jest mit 100% pokrycia kodu testami jednostkowymi. Co gorsza, mit ten ma się równie dobrze (a może nawet lepiej?) wśród decydentów (kierowników, dyrektorów itp.). Celem poniższej notki jest pokazanie, jak bardzo naiwne jest podejście "100% pokrycia". Popatrzmy na następujący trywialny kod:

Zapoznając się z tematyką testów jednostkowych napotykamy podział mocków na trzy grupy: Dynamic Mock, Strict Mock oraz Stub. Dziś pora na poruszenie tego tematu wraz z prezentacją jak je wykorzystać w Rhino Mocks.