Nie jest to pierwszy wpis o SpecFlow i podstawy framework’a znajdziecie oczywiście  w archiwum. W SpecFlow można definiować tzw. “Scenario outline”, które służą jako szablony dla testów. Oczywiście data-driven testing nie powinno być nadużywane i w szczególności dla acceptance tests nie ma to wielkiego sensu. SpecFlow jest często używany dla testów systemowych i UI, gdzie nie testujemy wszystkich możliwych kombinacji danych wejściowych. Czasami jednak chcemy mieć bardziej sparametryzowany zestaw testów...

Każdy z nas jest choć trochę leniwy. Jedni troszkę mniej, inni troszkę bardziej. Ja na ten przykład czasem się rozpędzam i piszę kod, który potrzebuje. Potem o nim opowiadam, a potem ktoś pyta czemu nie skorzystałem z jakiejś tam gotowej biblioteki. Wiem, że każdy z nas należy do mensy i wie, że ten wpis nie wziął się z powietrza.

Dzisiaj chciałbym przedstawić framework WatiN, który służy do automatyzacji testów. Symuluje on po prostu przeglądarkę internetową (dosłownie). Za pomocą niego, możemy otworzyć IE, wejść na daną stronę czy kliknąć w jakiś przycisk. Wszystkie operacje takie jak kliknięcie w link czy nawet maksymalizacja okna są możliwe dzięki WatiN. Docelowo używa go się w połączeniu z nUnit albo SpecFlow. Zacznijmy jednak od zwyklej aplikacji konsolowej. Załóżmy, że chcemy wejść na Google.pl, wpisać tekst i kliknąć w pr...

Jednym zdaniem NCrunch to narzędzie do automatycznego uruchamiania testów jednostkowych w Visual Studio. Pisałem już o NCrunch-u ale o tak świetnym dodatku warto napisać jeszcze raz i to z dwóch powodów. Po ostatniej prezentacji na ITAD na bielskiej ATH kilka osób pytało mnie o zielony pasek więc w ramach wyjaśnienia taki zielony pasek to wła...

Pewnie każdy na swojej ścieżce programistycznej spotkał się z klasą abstrakcyjną. Wrzucamy tam kod, który zdaje się być domyślną implementacją pewnej grupy klas i szkoda nam kopiować tego zachowania do każdej z nich osobna. Skoro wszystkie zachowują się podobny sposób, czasem tylko dodając coś od siebie, to warto wykorzystać dziedziczenie i napisać mniej (DRY).

Opublikowano We wpisie o pokryciu kodu (Code Coverage) napisałem: Należy pamiętać, że to są narzędzia dla programisty Co przez to rozumiem? Code Coverage nie może być używany przez kierownictwo/zarząd/management/etc – a już pod żadnym pozorem nie może być związany finansowo z wypłatą programisty. Dlaczego? Przyciśnięty programista może bardzo łatwo wygenerować dowolne pokrycie kodu i to przy dosyć małej ilości pracy. Pisząc odpowiednią ilość testów jednostkowych bez asercji można uzyskać 100% pokryci...

To jest mój pierwszy post, ale od czegoś trzeba zacząć. Wybacz więc niedociągnięcia :). Na pierwszy temat rzucam porównanie wydajności kilku bibliotek (framework'ów) do wstrzykiwania zależności (Dependency Injection), które jest częścią paradygmatu odwróconego sterowania (Inversion of Control) - więcej można przeczytać tutaj. Ostatnio przeczytałem, że znaczna większość programistów korzysta z tych dobrodziejstw. Niby dobrze, o ile wiemy z czym mamy do czynienia. Część bibliotek jest przeładowana ...

Moment pisania testów jest nierzadko kluczowy dla zmaksymalizowania efektywności całej procedury. Po kilku chwilach zastanowienia da się wyróżnić kilka najważniejszych etapów tworzenia oprogramowania, które z reguły są odpowiednią chwilą do implementacji testu.

Test jednostkowy to nic innego jak kod wykonujący inny kod w kontrolowanych warunkach. Jego zadaniem jest weryfikacja (bez ingerencji programisty), że testowany kod działa poprawnie. Robi to w sposób dość banalny: autor testu dostarcza dane wejściowe (input), test wykonuje pewne instrukcje i sprawdza, czy rezultat działań (output) zgodny jest z oczekiwaniami. W świecie idealnym każdy test bada jedną ścieżkę wykonania jednej metody. Czy jednak jedyną rolą testów jednostkowych jest sprawdzenie działania ...

Mamy problem z szeroko pojętą jakością oprogramowania. My, czyli nasza cywilizacja. Wciąż nie jesteśmy w stanie stworzyć oprogramowania, które nie będzie zawierało błędów. Nie jesteśmy też w stanie wychwycić wszystkich błędów na etapie testowania. I nie, nie chodzi mi tu (tylko) o błędy związane z bezpieczeństwem. Skutki błędów mogą być zarówno spektakularne (np. eksplozja rakiety Ariane 5), jak i tragiczne (np. ofiary śmiertelne źle działającego sprzętu medycznego). Mogą też być ciekawe, ostatnio przecz...