Artykuł: Techniki ułatwiające utrzymanie testów

Zapraszam do lektury kolejnego artykułu Rafała Jamroza z serii: Refaktoryzacja testów legacy w kierunku wykonywalnych specyfikacji.

Cytat ze wstępu: "W artykule przedstawiam techniki, które pomogą w pracy z testami w projekcie legacy (i nie tylko), a które profesjonalny programista powinien mieć w swojej „skrzynce z narzędziami”, czyli m.in. Test Data Builder i Assert Object. Mimo to należy pamiętać, że zrozumienie problemu, nad którym pracujemy, jest znacznie ważniejsze niż stosowane techniki i powoduje, że testy posiadają jeszcze większą wartość"

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego

Na YT opublikowano moją prezentację z zeszłorocznej konferencji JDD: https://www.youtube.com/watch?v=znRByMgnFSM

Czego możesz się z niej dowiedzieć:
- jeżeli testy używają Mocków "to wiedz, że coś się dzieje"
- jeżeli w typowym projekcie biznesowym dąży się do pokrycia 80% "to wiedz, że coś się dzieje"
- jeżeli testy akceptacyjne są napisane językiem kontrolek UI  "to wiedz, że coś się dzieje"
- jeżeli widzisz (anty) wzorzec Page Object "to wiedz, że coś się dzieje"
a poza tym testy end-to-end powinny mieć warstwy - jak wszystko:)

...oraz jak działają automatyczne skrzynie biegów w super-samochodach.


Materiały: http://prezi.com/cxslyh5sqo_z/czego-mama-nigdy-nie-mowia-ci-na-temat-testowania-automatycznego/

Nowe serie artykułów: zaawansowany Android i refaktoryzacja tesów

Udostępniliśmy do pobrania artykuły z nowych serii publikowanych w programistamag.pl przez moich współpracowników:

• Michał Charmas rozpoczął serię Zaawansowane programowanie na platformie Android artykułem There is no app - do pobrania tutaj: http://bottega.com.pl/artykuly-i-prezentacje#android
• Rafał Jamróz rozpoczął serię Refaktoryzacja testów legacy w kierunku wykonywalnych specyfikacji artykułem Podstawowy refaktoring testów - do pobrania tutaj: http://bottega.com.pl/artykuly-i-prezentacje#testowanie

Zapraszamy do lektury:)

JUG: 19-20 listopada Trójmiasto - DDD i testowanie

W imieniu swoim jak i Rafała zapraszam na warsztaty jakie będziemy prowadzić w przyszłym tygodniu w Gdańsku w ramach JUG korzystając z gościnności Spartez:

Modeling Whirlpool - warsztaty z modelowania DDD: https://www.eventbrite.com/e/modeling-whirlpool-warsztaty-z-modelowania-ddd-sawek-sobotka-tickets-9324093615

Jak wyprowadzić słabe i smutne testy na prostą: https://www.eventbrite.com/e/jak-wyprowadzic-sabe-i-smutne-testy-na-prosta-rafa-jamroz-tickets-9324528917

Piwo, kiełbasa i testowanie automatyczne

Starożytni celebrowali wino, kobiety i śpiew.
Cywilizacja poszła do przodu i współcześni dżaważe celebrują piwo, kiełbasę i testowanie automatyczne.

W imieniu organizatorów i swoim zapraszam na jPiknik: http://jpiknik.pl/ podczas którego przedstawię prezentację: Czego mama nigdy nie mówiła Ci na temat testowania automatycznego (prezi) oraz wraz z Rafałem poprowadzimy warsztat Jak wyprowadzić słabe i smutne testy na prostą oparty na doświadczeniach coachingowych Rafała.

14 września w Temat Rzeka na Plaży przy Moście Poniatowskiego w Warszawie, wstęp wolny.

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

Dla zainteresowanych warsztatem: Rafał poprowadzi reedycję na tegorocznej Warsjawie.

Materiały z konferencji 33rd Degree

Oto obiecane materiały:

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego - problemy, strategie, taktyki, techniki i narzędzia






Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się w ciągu 6 lat stosowania i nauczania DDD






Dodatkowo dla osób, które pytały o inne prezentacje:

Architektura Ports & Adapters
Wstęp do DDD: Domain Driven Design - A place for everything and everything in its place
Architektura CqRS: Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw

Projekt referencyjny: DDD & CqRS Sample Leaven


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

Jak zwykle feedback odnośnie prezentacji mile widziany - może być na prv.

Mock czy Stub? Command-query Separation prawdę ci powie.

Testując jednostkowo sieć powiązanych obiektów, dążymy do ich testowania w separacji. Separację osiągamy dzięki stosowaniu różnego rodzaju „dublerów”.

Często bez zastanowienia stosujemy dublery typu Mock. Mocki są relatywnie pracochłonną techniką, która nie zawsze jest uzasadniona - czasem wystarczający jest Stub (Fowler o różnicy pomiędzy Mock a Stub: Mocks Aren't Stubs).


W najnowszym wydaniu programistamag.pl opublikowałem artykuł zatytułowany "Mock czy Stub? Command-query Separa-tion prawdę ci powie." przedstawiający pragmatyczną „reguła kciuka” oparta o paradygmat Command-query Separation, która daje prostą odpowiedź co do typu dublera, jakiego potrzebujemy w teście jednostkowym.

Artykuł tradycyjnie do pobranie (całkowicie darmowo) tutaj: http://www.bottega.com.pl/artykuly-i-prezentacje.

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

Dla niecierpliwych esencja reguły:

• metody typu query -> użyj Stub
• metody typu command -> użyj Mock

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