1 Zaawansowane techniki obiektowe
2 Ewolucja obiektów czyli Programowanie Sterowane…Driven TDD BDD ATDD DDD
3 TDD Test Driven Developmet/Design Testy Testy przed kodemRed-Green-Refactor Test jednostkowy Czy jednostkowy oznacza jedna klase ? Jak bardzo jednostkowy musi byc test ?
4 BDD Behavior Driven D* Poprawnie robione TDD ?Piszemy testy czy może specyfikujemy zachowanie ? Wartość biznesowa co to znaczy użyteczny test? Test powinien wyrażać zachowanie co to znaczy zrozumiały test ? czy wystarczy zrozumiały tytuł?
5 BDD - kierunki Zachowania na poziomie kodutesty jednostkowe narzedzia np. MSPEC Zachowania na poziomie system testy end to end / akceptacyjne narzedzia np. cucumber/Specflow
6 ATDD Acceptance Test Driven D*Jak opisać i sprawdzić zachowanie systemu? Jak wyrazić testy w sposób zrozumiały dla biznesu? Duża i mała pętla: Test Akceptacyjny TDD/BDD aż zrealizujemy test akceptacyjny Problemy: Stan bazy, Interakcje z GUI
7 Cucomber – przykładowy sposób wyrażania wymagańPrzykładowy scenariusz
8 Cucomber – podstawowe definicje
9 Cucomber – test nie przechodzi
10 Cucomber – troche wiecej kodu
11 Cucomber – i test przechodzi
12 Baza - trudności Stan bazy sie zmienia ….Niedotykalne/odtwarzane dane testowe Przeładowanie bazy przed każdym testem Przeładowanie bazy przed testami Testy z robackowaną transakcją Testy samo kompensujące “Inteligentne” testy dostosowujące się do stanu bazy
13 GUI - trudności Wrażliwość na zminy wyglądu, rodzaj przeglądarki itdSelenium + page objects A może troche "pooszukiwać" na poziomie API/pomiędzy.
14 Obszar pomiędzy czyli kompromis…czyli testy integracyjne UT POWINNY BYĆ tanie, masowe, szybkie
15 Rożek lodów Antywzorzec najpowszechniej-sze to, co drogie
16 Testy integracyjne … czy aby nie testy zintegrowane? Przy podejściach uSerwisowych niezwykle ważne jest odesparowanie serwisów w rune-time w developmencie w testowaniu Proby tesowania kilku skomplikowanych bytów razem prowadzą (nieuchronnie?) do problemów Do posłuchania: (i inne J. B. Rainsberger)
17 Continuous development
18 Continuous developmentNa podst. WIKIPEDIA
19 Ciągła integracja vs. dostawaCI: Cykliczna budowa artefaktów + uruchomienie podstawowych testów rzadkie buildy = dużo zmian – kto winien problemów? testy mogą trwać b. długo długo -> podział na rózne sety podstawowe, rozszerzone, o różnym wpływie na build żeby uruchomić testy integracyjne/funkcjonalne trzeba wdrożyć … coś (komponent/bazę/dane) automatyzacja instalacji pozwala wdrażać (i testować) również w srodowiskach docelowych (UAT/Stage/Prod) DevOps Spotify releasy co 17s?
20 DevOps https://spotifylabscom.files.wordpress.com/2014/03/spotify-engineering-culture-part1.jpeg
21 Continuous delivery Wdrożenia – uzgodnienia z infrastructure teamKonfiguracje – wersjonowanie, aplikowanie wewnątrz pakietów instalacyjnych ? hasła? uprawnienia? Wersjonowanie baz (search?) Infrastruktura provisioning maszyn, instalacja systemów, uaktualnienia i wersjownowanie Wirtualizacje, lekkie wirtualizacje
22 Narzędzia Team city Automatyzacja deplymentów: Chef, Puppet, PShRunnery do testów Automatyzacja deplymentów: Chef, Puppet, PSh Zarzadzane konfiguracją: Configatron Bazy: Entity migration, np. Roundhouse Docker
23 Domain Driven Design Jak często implementowali Państwo FFT?Na czy polega problem z Sytemami Informatycznymi? Proste operacje zwielokrotnione 1000x synergia ciągłe zmiany
24 Komplikacja problemu Esencjonalna Przypadkowa wynika z natury problemuniemożliwa do uniknięcia Przypadkowa wynika z podejścia lub konkretnych rozwiązań może rosnąć (i zwykle rośnie) z czasem
25 Co to jest?
26 Co to jest?
27 Model User interface Infrastructure Application logic Domain logic wyraża reguły, procesu, obejmuje główną logikę, jest sercem system stanowi (poninien) największą wartość powstaje długo, wymaga pielęgnacji model to nie dane (scheme DB) ani zachowanie model obejmuje wiedzę wydestylowaną przez realizujących system (i powinien być czytelny!)
28 Model wyraża reguły, procesu, obejmuje główną logikę, jest sercem system stanowi (poninien) największą wartość powstaje długo, wymaga pielęgnacji model to nie dane (scheme DB) ani zachowanie model obejmuje wiedzę wydestylowaną przez realizujących system (i powinien być czytelny!)
29 Wszechobecny Język język ekspertów dziedzinowych vs IT różne obszaryUbiquitous language różne obszary np. co znaczy użytkownik, faktura ? ważny jest kontekst użycia bounded context
30 Wzorce wartości, encje, sewisy, agregatyDomain Layer (Business Logic) Aggregate Entity (Aggregate root) Value Object business methods Delegate Load Save Business Service <
31 Więcej Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software Vaughn Vernon Implementing Domain-Driven Design Slawomir Sobotka model jest wszystkim czego potrzebujesz https://www.youtube.com/watch?v=iaLeKHbspLg A place for everything and everything in its place https://www.youtube.com/watch?v=jraV7xSTYVs
32 Więcej Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software Vaughn Vernon Implementing Domain-Driven Design Slawomir Sobotka model jest wszystkim czego potrzebujesz https://www.youtube.com/watch?v=iaLeKHbspLg A place for everything and everything in its place https://www.youtube.com/watch?v=jraV7xSTYVs