1 Poznań, 28.10.2014, Artur OtrzonsekInsert Client/Partner logo Clean Code, TDD, Mockito Poznań, , Artur Otrzonsek

2 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

3 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

4 Jak zmierzyć jakość koduSource: „Clean Code”, Robert C. Martin Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

5 Dlaczego czytelność kodu jest ważna?Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

6 Wpływ bałaganu w kodzie na wydajność zespołuŹródło: „Clean Code”, Robert C. Martin Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

7 Ciągła poprawa kodu jest możliwa!„Wprowadzaj do repozytorium kod lepszy niż ten, który z niego pobrałeś” Źródło: Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

8 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

9 Nazywamy wszystko – róbmy to dobrzeZmienne Metody Używaj znaczących nazw Katalogi Argumenty Pliki Klasy Pakiety Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

10 int g; // suma godzin pracyZmienne int g; // suma godzin pracy int sumaGodzinPracy; Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

11 Metody Metody powinny być krótkie (~20 linii kodu)Tylko jeden poziom abstrakcji w metodzie Dekompozycja złożonej metody na mniejsze Pomaga dokumentować kod Czytelne sygnatury metod Max 3-4 parametry Szczególnie uciążliwe są parametry o tych samych typach Argumenty przełączające Parametry boolean, enum często wskazują na to, aby dodać nową metodę Unikać powtarzającego się kodu DRY (Don’t Repeat Yourself) Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

12 Metody - długa lista parametrówpublic ListfindUsers(Long countryId, Long stateId, boolean isActive, boolean isAdmin, boolean isChief, boolean isCustomer, boolean isForeigner, String countryCode, String stateCode, String streetName, int minAge, int maxAge, …) {...} public ListfindUsers(UserSearchParameter searchParameter) {...} Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

13 Metody - długa lista parametrów - wywołaniepublic List users = findUsers(1L, null, true, false, false, false, false, "PL", null, null, 20, 50, …) {...}; Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

14 Metody - długa lista parametrówclass UserSearchParameter { private Long countryId; private boolean active; // getters and setters } class UserSearchParameterBuilder { private UserSearchParameter searchParameter = new UserSearchParameter(); public UserSearchParameterBuilder onlyActive() { searchParameter.setActive(true); return this; } public UserSearchParameter build() { return searchParameter; Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

15 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

16 Testy jednostkowe Dokumentują kod i ułatwiają zrozumienie jego działania Ułatwiają refaktoryzację kodu Kod testów nie jest kodem drugiej kategorii! Powinny być czytelne Będą zmieniane w trakcie zmian kodu produkcyjnego Tylko jedna koncepcja jest testowana w jednym teście Czyste testy powinny być zgodne z zasadą „F.I.R.S.T.”: Fast (szybkie) Independent (niezależne - nie powinny zależeć od siebie) Repeatable (powtarzalne w każdym środowisku) Self-Validating (samodzielnie sprawdzające wynik) Timely (napisane „o czasie”, przed kodem produkcyjnym) Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

17 Tylko jedna koncepcja jest testowana w jednym teściepublic void testShouldReturnEmptyListWhenUserHasNoRoles() { // given userController.addUser(createUser(USER_MAIL)); User user = userController.findUser(USER_MAIL); // when List roles = userController.findRoles(user.getId()); // then assertTrue(roles.isEmpty()); } Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

18 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

19 Komentarze Kod powinien sam się opisywaćZnaczące nazwy, krótkie metody, itd.. Komentowanie kodu staje się przestarzałe Po zmianie kodu najczęściej komentarz pozostaje niezmieniony Są przydatne gdy wyjaśniają coś czego nie da się czytelnie opisać w kodzie Przykłady złego komentowania: Przeczytanie komentarza zajmuje więcej czasu niż analiza kodu Komentarz jest nieaktualny Zawiera powtórzone informacje które można wyczytać z kodu Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

20 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito1 Please discover "Update Agenda" in your Capgemini Tools to get all the agenda slides and to refresh them; there is also a layout without picture in the background available Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

21 TDD (Test-Driven Development)Source: Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

22 TDD – trzy podstawowe prawaZabronione jest pisanie kodu produkcyjnego do czasu zaimplementowania testu. Test rozwijamy do momentu aż wykryje pierwszy błąd w kodzie produkcyjnym. Poprawiamy kod produkcyjny do momentu naprawy niedziałającego testu. Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

23 TDD – zalety Pewność Odwaga Dokumentacja Zarys, projektDziesiątki testów napisanych codziennie, setki w tygodniu, a tysiące w roku Wszystkie te testy zostaną odpalone w trakcie refaktoryzacji kodu Odwaga Reakcja na zmianę w „czyimś” kodzie Dokumentacja Każdy napisany test opisuje działanie jakiejś funkcjonalności Zarys, projekt Testy wymagają izolacji, a to wymusza implementację zgodną z Clean Code Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

24 Agenda Clean Code Znaczące nazwy Testy Komentarze TDD MockitoCopyright © Capgemini All Rights Reserved poznan_clean_code.pptx

25 Mockito Twórcą projektu jest Szczepan FaberPowstał w odpowiedzi na uciążliwe korzystanie z mocków podczas budowy testów Reprezentuje odmienne podejście typu spy test bardziej naturalne, prowadzi do przejrzystego kodu Proste i przejrzyste API Czytelne komunikaty o błędach Bardzo dobra dokumentacja Copyright © Capgemini All Rights Reserved poznan_clean_code.pptx

26 Mockito, jak to działa Copyright © Capgemini 2013. All Rights Reservedpoznan_clean_code.pptx

27 Mockito, przechwytywanie argumentówCopyright © Capgemini All Rights Reserved poznan_clean_code.pptx

28