Zaawansowane techniki obiektowe

Prezentacja na temat: "Zaawansowane techniki obiektowe"— Zapis prezentacji:

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 kodem
Red-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 kodu
testy 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 itd
Selenium + 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 development
Na podst. WIKIPEDIA

19 Ciągła integracja vs. dostawa
CI: 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

21 Continuous delivery Wdrożenia – uzgodnienia z infrastructure team
Konfiguracje – 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, PSh
Runnery 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 problemu
niemoż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 obszary
Ubiquitous language różne obszary np. co znaczy użytkownik, faktura ? ważny jest kontekst użycia bounded context

30 Wzorce wartości, encje, sewisy, agregaty
Domain Layer (Business Logic) Aggregate Entity (Aggregate root) Value Object business methods Delegate Load Save Business Service <<interface>> Policy (Strategy Design Pattern) Application Layer (Application Services, Use Case Agents) PolicyImpl1 PolicyImpl2 Repository Factory Event Generate Create wartości, encje, sewisy, agregaty budowniczy, fabryka, repozytorium, polityka warstwy, zdarzenia

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 A place for everything and everything in its place

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 A place for everything and everything in its place