Testowanie automatyczne - artykuł

W najnowszym numerze programistamag.pl ukazał się kolejny artykuł z serii DDD: "Kompendium testowania aplikacji opartej o DDD – problemy, strategie, taktyki i techniki".

Artykuł można pobrać również tutaj: http://bottega.com.pl/artykuly-i-prezentacje (całkowicie free:).

Problem testowania automatycznego został osadzony w kontekście DDD, ale traktuje o testowaniu w ogólności, tak więc lektura powinna być pożyteczna dla każdego programisty i projektanta. Proponujemy w nim nieco inne spojrzenie na klasyczną już piramidę testów - dosłowne mapowanie piramidy na architekturę warstwową oraz nieco inne spojrzenie na pokrycie kodu testami.

Treść została uporządkowana wg struktury: Problemy, Strategie, Techniki, Taktyki i Narzędzia.

Jest to autorska metodyka opracowana w naszej firmie, którą stosujemy podczas coachingu z zakresu testowania automatycznego, składająca się z 2 etapów:

• W fazie analizy sytuacji poruszamy się ścieżką top-down aby zdiagnozować cele na każdym poziomie w kontekście poziomu wyższego.
• Natomiast w fazie wdrażania (coachingu) poruszamy się ścieżka bottom-up aby skupić się tylko na tych aspektach, które wprowadzają największą wartość.

Jeżeli wdrażasz (lub planujesz wdrożyć) zmiany we własnej organizacji to zachęcamy do wypróbowania tego podejścia i podzielenia się spostrzeżeniami.

//=======================================

Jednak główne przesłanie artykułu to: "unikaj pracy z serwerem aplikacji i bazy danych". Ile czasu zajmuje Ci cykl od momentu wciśnięcia ctrl+s w swoim IDE do przekonania się czy zmiany w kodzie są poprawne? Kilkanaście minut? Próba hotdeploymentu, przeładowanie aplikacji, które kończy się restartem serwera, przygotowanie danych, przeklikanie kilkunastu formularzy (każdy po kilka zakładek z kilkunstaoma polami) aby wreszcie zobaczyć np złą kwotę po naciśnięci "Zatwierdź" na ostatnim formularzu.

Czy po to studiowałeś/studiowałaś 5 lat?

Dzięki wydzieleniu warstwy domenowej, a w niej posługiwaniu się Bulding Blocks zgodnie z zasadami DDD osiągamy wysokie testability kodu, które pozwala na pracę z pojedynczymi fragmentami modelu przy pomocy testów jednostkowych (tanich w stworzeniu, bo unikamy sytuacji gdy potrzeba stworzyć Mock/Stub/Fake).