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

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito 1 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 2013. All Rights Reserved poznan_clean_code.pptx

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito 1 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 2013. All Rights Reserved poznan_clean_code.pptx

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

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

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

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

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito 1 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 2013. All Rights Reserved poznan_clean_code.pptx

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

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

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 2013. All Rights Reserved poznan_clean_code.pptx

Metody - długa lista parametrów public List<User>findUsers(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 List<User>findUsers(UserSearchParameter searchParameter) {...} Copyright © Capgemini 2013. All Rights Reserved poznan_clean_code.pptx

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

Metody - długa lista parametrów class 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 2013. All Rights Reserved poznan_clean_code.pptx

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito 1 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 2013. All Rights Reserved poznan_clean_code.pptx

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 2013. All Rights Reserved poznan_clean_code.pptx

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

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito 1 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 2013. All Rights Reserved poznan_clean_code.pptx

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 2013. All Rights Reserved poznan_clean_code.pptx

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito 1 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 2013. All Rights Reserved poznan_clean_code.pptx

TDD (Test-Driven Development) Source: http://diogoosorio.com/public/images/blog/tdd_flow.gif Copyright © Capgemini 2013. All Rights Reserved poznan_clean_code.pptx

TDD – trzy podstawowe prawa Zabronione 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 2013. All Rights Reserved poznan_clean_code.pptx

TDD – zalety Pewność Odwaga Dokumentacja Zarys, projekt Dziesią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 2013. All Rights Reserved poznan_clean_code.pptx

Agenda Clean Code Znaczące nazwy Testy Komentarze TDD Mockito Copyright © Capgemini 2013. All Rights Reserved poznan_clean_code.pptx

Mockito Twórcą projektu jest Szczepan Faber Powstał 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 2013. All Rights Reserved poznan_clean_code.pptx

Mockito, jak to działa Copyright © Capgemini 2013. All Rights Reserved poznan_clean_code.pptx

Mockito, przechwytywanie argumentów Copyright © Capgemini 2013. All Rights Reserved poznan_clean_code.pptx