In the last semester (Fall 2013) I had a pleasure to take course CIS706 – Translator Design (aka Compilers) with Dr Robby at Kansas State University. It was great experience! I think it is the best course I have ever taken. The way how this course is designed is just amazing...

W poprzednim poście poruszyłem temat mojego side-projectu (który BTW nie powinien zająć więcej niż 2-3 dni, ale lubię dawkować przyjemności więc pewnie jeszcze trochę to potrwa;) ) i MSpec. Teraz zobaczymy jak można w bardzo ciekawy sposób przetestować WebAPI emulując dosłownie całego requesta z kodu, co miło przejedzie przez kompletny stack i sprawdzi nie tylko logikę, ale również m.in. konfigurację routingu… a docelowo tak...

Testy jednostkowe “czasu” nie są tematem łatwym. Rozsiane po całej aplikacji wywołania DateTime.Now (które i tak powinny być odwołaniami do DateTime.UtcNow) nie upraszczają tej kwestii. Problem ten można rozwiązać na kilka sposobów...

Przeglądając kod wielu projektów, zarówno komercyjnych jak i open source, można spotkać całą masę konwencji nazewniczych stosowanych do klas i metod testujących. Dzisiaj przedstawię kilka moich zasad w tej materii wraz z uzasadnieniem. Wychodzę z założenia, że bardziej niż konwencja, standard czy "przyjęta dobra praktyka" liczy się czytelność pisanego kodu i łatwość powrotu do niego nawet po kilku miesiącach od napisania. Dlatego też w swoich projektach nie mam zdefiniowanej jedynego słusznego schematu n...

W komentarzach do ostatniego posta wywiązała się dyskusja na temat "a co z metodami prywatnymi?". Odpowiedź najkrótsza z możliwych brzmi: NIC. Zainteresowanych odsyłam do tamtejszych wypowiedzi, a w niniejszej notce postaram się zawarte tam myśli rozwinąć. Zaczynając przygodę z testami jednostkowymi często stawałem przed dylematem "jak mam przetestować funkcjonalność z metod prywatnych?". Sporo się naszukałem i naczytałem o różnych rozwiązaniach, z czego dwa zdawały się być najpopularniejsze i najbardzi...

Od jakiegoś czasu staram się wykształcać w sobie nawyk regularnego pisania testów jednostkowych dla wykrytych błędów. Dlaczego? Możliwość sprawdzenia działania programu przy pomocy testów jednostkowych jest najprostszym wskaźnikiem jakości (choć bardzo ogólnym i nie jedynym!) wytwarzanego kodu. Testy jednostkowe są swego rodzaju drogowskazem, który stale pokazuje programiście dobry kierunek "jeżeli-czegoś-nie-można-przetestować-to-trzeba-to-przebudować".

Testowanie kodu wielowątkowego jest nie lada wyzwaniem. Teoretycznie powinno się tego unikać, ale czasami nie ma innego wyjścia. Co robić w sytuacji, gdy w komponencie tworzonym podczas naszego testu uruchamiany jest nowy wątek, a w nim wyskakuje wyjątek? Test oczywiście nie przechodzi, ale wcale niekoniecznie musimy wiedzieć dlaczego tak a nie inaczej się stało. Kiedyś pół godziny straciłem na wgapianie się w monitor zanim wpadłem na to, że w wątku pobocznym wyskakuje wyjątek. Bo jak wiadomo, wyjątek rz...

Jak powszechnie wiadomo - wielką zaletą wzorca MVC jest umożliwienie testowania jednostkowego logiki "wyciągniętej" z klas odpowiedzialnych za interakcję z użytkownikiem. Swego czasu śledziłem w internecie dyskusje na temat "Jak testować kontrolery, aby możliwie najbardziej odizolować je od reszty aplikacji". O to przecież chodzi w Unit Testing...

Podczas pisania testów jednostkowych możemy natknąć się na problem uprawnień – co jeśli testowana metoda wymaga, aby użytkownik był zalogowany, miał określoną nazwę bądź był przypisany do konkretnej roli? Nie chcemy przecież, aby testy jednostkowe w jakiś sposób logowały się do naszej aplikacji. Rozwiązaniem jest pomocnicza klasa, którą napisałem z wykorzystaniem frameworka Moq:

Testowanie obsługi zdarzeń oraz faktu ich wywołania jest niekiedy równie ważne co przetestowanie każdej innej integracji pomiędzy dwoma obiektami. Scenariusz jest na tyle specyficzny, że poświęcę mu osobną notkę.