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