Technologia Programowania 2016/2017 Wykład 6 Mockito, wzorce GoF, MVC Jakub Lemiesz
Lista zadań na laboratorium 2 / 48
Testowanie Tradycyjnie: testy jednostkowe, integracyjne, systemowe, testy akceptacyjne (alfa i beta) Metodyki agile: testowanie po każdej iteracji, ciągła integracja, ciągły kontakt z klientem Agile Testing Quadrnats klasyfikacja testów w metodykach agile (nic nie mówi o kolejności) 3 / 48
4 / 48
Testowanie jednostkowe, testowanie komponentów Cel: szybko i automatycznie testować małe elementy w izolacji (TDD, refaktoryzacja) System Under Test (SUT) może zależeć od wielu Depended On Components (DOCs) 5 / 48
Dlaczego zależność od DOCs jest problem? 1 DOCs nie są gotowe 2 Do testów DOCs o szczególnych właściwościach (np. generator l. losowych zawsze zwracający π) 3 Odwołanie do DOC może mieć skutki uboczne (np. połączenie z prawdziwą bazą danych) 4 Stworzenie i użycie prawdziwych DOCs może być czasochłonne a testy mają być szybkie (testy integracyjne to późniejszy etap) 6 / 48
Dummy Objects, Fakes Dummy Object np. metoda w SUT wymaga parametru, ale dla testu nie ma znaczenia jaki jest ten parametr Fake gdy DOC jest niedostępny albo nie nadaje się do testów tworzymy lekką klasę zastępczą Żeby stworzyć Dummy Object lub Fake nie potrzebujemy dodatkowych narzędzi 7 / 48
Dlaczego Mockito? Zamiast DOC można użyć tzw. dublera, który ma taki sam interfejs jak DOC, jest lżejszy i może wykonywać pewne dodatkowe zadania (Stubs, Spies, Mocks) Systemy do mokowania są bardzo powszechnie używane: np. JMockit, EasyMock i dziesiątki innych dla Java i C# Mockito jest jednym z popularniejszych systemów (autor biblioteki: Szczepan Faber) 8 / 48
Stubs czyli kikuty Tworzymy dublera, który ma zamiast metod kikuty. W testach (np. JUnit) piszemy tak: //Dlaczego static? import static org.mockito.mockito.*; //Można mokować klasy albo interfejsy LinkedList mocklist = mock(list.class); //stubbing - kikutowanie? when(mocklist.get(0)).thenreturn("first"); when(mocklist.get(1)).thenthrow(new Exception( when(mocklist.get(anyint())).thenreturn("x"); 9 / 48
Spies czyli śledzenie prawdziwych obiektów Chcemy mieć pewność, że prawdziwy DOC zachowuje się w odpowiedni sposób: List list = new LinkedList(); List spy = spy(list); //wywołanie prawdziwych metod spy.add("one"); verify(spy).add("one"); //możemy zasłonić metody when(spy.size()).thenreturn(100); System.out.println(spy.size()); 10 / 48
Mocks czyli szpiegowanie kikutów Chcemy mieć pewność, że SUT zachowuje się poprawnie i komunikacja między SUT a DOC przebiega we właściwy sposób: mocklist.add("a"); //weryfikacja wywoływania metod verify(mocklist).add("a") verify(mocklist).add("b") //weryfikacja kolejność wywoływania InOrder inorder = inorder(mocklist); inorder.verify(mocklist).add("a"); inorder.verify(mocklist).add("b"); 11 / 48
Mocks w Mockito sporo możliwości //exact number of invocations verification verify(mockedlist, never()).add("a"); verify(mockedlist, atleastonce()).add("a"); verify(mockedlist, times(2)).add("a"); verify(mockedlist, atleast(2)).add("a"); verify(mockedlist, atmost(5)).add("a"); //firstmock wywołany przed secondmock InOrder inorder = inorder(firstmock, secondmock); inorder.verify(firstmock).add("was called first"); inorder.verify(secondmock).add("was called second"); //mocktwo i mockthree się nie komunikowały verifyzerointeractions(mocktwo,mockthree); 12 / 48
Mocks w Mockito matechrs //przykładowe matchery typów verify(mock).somemethod(anyint(), anystring()); verify(mock).somemethod(eq("third argument")); verify(mock).somemethod(argthat(isvalid())); //własne matchery class IsListOfTwoElements extends ArgumentMatcher<List> public boolean matches(object list) { return ((List) list).size() == 2; } } verify(mock).addall(listoftwoelements()); 13 / 48
Więcej o Mockito na: mockito.github.io/mockito/docs/current/org/ mockito/mockito.html 14 / 48
Wzorce GoF Kreacyjne Builder Singleton Simple Factory Factory Method Abstract Factory Prototype Strukturalne Adapter Decorator Proxy Composite Facade Flyweight Bridge Czynnościowe Strategy Template Method State Command Observer +MVC Mediator Interpreter Iterator Visitor Memento 15 / 48
Wzorce GoF w standardowych bibliotekach Javy http://stackoverflow.com/questions/1673841/ examples-of-gof-design-patterns-in-javas-core-libraries 16 / 48
Mockito Flywieght Command Mediator Observer + MVC GoF: Flywieght, czyli waga musza B Przykład Pereiry: serwis www udostępniający wyniki pomiarów sensorów rozsianych po świecie B Trzy sensory (temperatura, wilgotność, wiatr) są zawsze instalowane razem i tworzą stację pogodową B Stacje pogodowe są pogrupowane w strefy 17 / 48
Flyweight: diagram sekwencji w przykładzie http://allweatherservice.com/aveiro?la=037=&lo=0838 18 / 48
Flywieght: diagram klas w przykładzie 19 / 48
Flyweight, czyli waga musza Dla każdego klienta tworzymy wątek i instancję kontrolera. Instancja ma zajmować mało pamięci, bo w jednej chwili klientów może być bardzo dużo... (zużycie pamięci sprawdzimy za pomocą JMater) 20 / 48
Flywieght dwa główne pomysły 1) Wspólne dane wielu instancji pamiętamy raz! (intrinsic vs. extrinsic state, np. wyciągnięcie informacji o położeniu geograficznym kontrolerów) 2) Fabryka lekkich obiektów odpowiedzialna za zarządzania ich liczbą i przydzielaniem do klientów 21 / 48
class WeatherStationControllerFactory { Map<String, WeatStatContr> controllers;//string to adres WeatStatContr getcontroller(string ipaddress) { WeatStatContr c = controllers.get(ipaddress); if (c == null) { c = new WeatStatContr(...); controllers.put(ipaddress, c); } return c; W kliencie WeatStat station = city.findneareststation(lat, long); String ip = station.getipaddress();... = WeatStatContrFactory.getIns().getController(ip); 22 / 48
Flywieght ogólny schemat employees.oneonta.edu/higgindm/sweng/csci311_course_notes.htm 23 / 48
GoF:Command czyli obiekty-polecenia Chcemy przechowywać zadania by wykonać je np. w odpowiedniej kolejnośc albo jako transakcję Przykłady: 1 transakcje bazodanowe 2 akcje GUI, edycja dokumentu - polecenia można układać na stosie i cofać (zadanie na ćwiczenia) 3 obsługa zdarzeń: np. serwer odbiera żądania, tworzy obiekty poleceń i określa ich priorytety 24 / 48
GoF:Command idea 1 Zamykamy wszystkie polecenia w ramach obiektów-poleceń o wspólnym interfejsie, np. interfejs ICommand z metoda execute(...) 2 Stworzone obiekty-polecenia przekaż do specjalnej klasy Invoker odpowiedzialnej przechowywanie, kolejkowanie i wykonanie 25 / 48
GoF:Command ogólny schemat 26 / 48
GoF:Command ogólny schemat 27 / 48
GoF:Command przykład Transakcje bazodanowe: 1 Transakcja zbiór poleceń insert, update, delete 2 Transakcja to czynność atomowa, tzn. wszystkie zadania muszą być wykonane albo żadne z nich 3 Kolejność poleceń istotna (spójność danych [1]): insert update delete 28 / 48
GoF:Command przykład 29 / 48
GoF: Mediator Problem: wysokie sprzężenie między obiektami, mamy zależności wiele-do-wielu Rozwiązanie: definiujemy nowy obiekt opisujący jak grupa obiektów ma współpracuje. Obiekty zależą jedynie od mediatora (np. kontrolera w MVC) 30 / 48
GoF:Mediator podstawowy schemat 31 / 48
GoF:Mediator przykład z Gamma et al. Okienko dialogowe jest mediatorem dla widgetów, które zawiera i które są ze sobą powiązane na różne sposoby (np. wybór z list box ustawia entry field) 32 / 48
GoF:Mediator przykład z Gamma et al. 32 / 48
GoF:Mediator komunikacja Komunikacja między Mediator a Peers może być zrealizowana na kilka sposobów 1 zwyczajna delegacja zadań za pomocą dedykowanych metod publicznych w mediatorze 2 zgodnie z wzorcem Observer (jak w MVC) 3 wiadomości asynchroniczne (będzie przy Akka) 33 / 48
GoF:Mediator zalety Ułatwia zarządzanie logiką komunikacji, która zostaje zamknięta w jednej klasie (redukuje relacje wiele-do-wielu na jeden-do-wielu ) Zmniejsza sprzężenie między klasami Peers (łatwe przenoszenie i tworzenie nowych klas) Wzorzec Mediator jest podobny do Facade, ale tam komunikacja w jedną stronę 34 / 48
GoF:Observer, czyli związek podmiot-obserwator Problem: 1 Wiele różnych obiektów-obserwatorów jest zainteresowanych na bieżąco zmianami zachodzącymi w obiekcie-podmiocie 2 Obserwatorzy mogą stracić zainteresowanie... 3 Low Coupling: obiekt-podmiot powinien mieć mało powiązań z obiektami-obserwatorami 35 / 48
GoF: Observer schemat komunikacji Rozwiązanie: 1 Definiujemy interfejs obserwatora 2 Obserwatorzy są rejestrowani na liście podmiotu 3 Podmiot informuje obserwatorów o zdarzeniach 36 / 48
GoF:Observer push vs. pull push podmiot wysyła wszystkie informacje pull obserwator wywołuje publiczne metody podmiotu 37 / 48
GoF:Observer podmiot ma listę obserwatorów 38 / 48
GoF:Observer na przykładzie MVC Przeanalizuj przykład: http://juristr.com/blog/2008/03/logical-separation-with-mvc/ 39 / 48
GoF:Observer na przykładzie MVC 39 / 48
MVC zdarzenia w GUI //gdzieś w JFrame import java.awt.event.*;... jbutton.addactionlistener( new ActionListener() { public void actionperformed(actionevent e) { controller.changeage(jtextfield.gettext()); } } ) Gdzie jest Subject, Observer, addobserver(), update()? Która klasa jest anonimowa? 40 / 48
MVC aktualizacja modelu //gdzieś w JFrame controller.changeage(jtextfield.gettext()); //gdzieś w kontrolerze public void changeage(string newvalue){ for (AbstractModel model: registeredmodels) { model.setage(newvalue); } 41 / 48
MVC aktualizacja modelu //gdzieś w JFrame controller.changeage(jtextfield.gettext()); //gdzieś w kontrolerze public void changeage(string newvalue){ for (AbstractModel model: registeredmodels) { model.setage(newvalue); } //w przykładzie do domu użycie refleksji //do szukania odpowiedniej metody w modelu try{ Method m = model.getclass().getmethod( setage ); m.invoke(model, newvalue); } 41 / 48
MVC zdarzenia w modelu 42 / 48
MVC zdarzenia w modelu 1 java.beans.propertychangesupport klasa umożliwiająca w podmiocie obsługę obserwatorów: wstawiamy pole z instancją tej klasy i delegujemy zadania (np. add, update) 2 addpropertychangelistener (String propertyname, PropertyChangeListener listener) 3 konstruktor PropertyChangeEvent (Object source, String property, Object old, Object new) 4 firepropertychange(propertychangeevent evt) notifyobservers() 5 PropertyChange(PropertyChangeEvent evt) update() 43 / 48
MVC zdarzenia w modelu public abstract class AbstractModel{ protected PropertyChangeSupport pcs = new... addpropertychangelistener(propertychangelistener l) { pcs.addpropertychangelistener(l); } firepropertychange(propertychangeevent evt) { pcs.firepropertychange(evt); } 44 / 48
MVC zdarzenia w modelu public class Person extends AbstractModel { // dodajemy kontroler do listy obserwatorów, // będzie powiadomiony przez firepropertychange String firstname; setage(int age) { int oldv = this.age; this.age = age; evt = new PropertyChangeEvent(this, Age,oldV,age); firepropertychange(evt); } 45 / 48
MVC kontroler pełni rolę mediatora //kontroler zdarzenie odebrane z modelu przesyła do widokó public class Controller implements PropertyChangeListener { private ArrayList<IView> registeredviews; public void propertychange(propertychangeevent evt) { } for (IView view: registeredviews) { view.modelpropertychange(evt); } //interfejs dla widoków interface IView { public void modelpropertychange(propertychangeevent evt); } 46 / 48
MVC zdarzenie w modelu, zmiany w widoku public class PersonView implements IView { modelpropertychange(propertychangeevent evt) { if(evt.getpropertyname().equals("age")) { String value = evt.getnewvalue().tostring(); jtextfieldage.settext(value); } else... 47 / 48
MVC kontroler jako mediator public class Controller implements PropertyChangeListen { ArrayList<IView> registeredviews; ArrayList<AbstractModel> registeredmodels; //foreach new model m registeredmodels.add(m); m.addpropertychangelistener(this); //foreach new view v registeredviews.add(v); v.add...listener(this); //this == Controller 48 / 48