•  

    Cześć, zapraszamy na drugą część miniserii z działu testów jednostkowych w Javie. Tym razem omawiamy Mocki. ( ͡° ͜ʖ ͡°)

    Mocki to obiekty, które imitują zachowanie prawdziwych obiektów i prawdziwego kodu. Zadaniem programisty jest zaprogramowanie odpowiedniego działania mocków.

    Film na YouTube | Wpis na blogu

    Nasz blog, kanał YouTube, Grupa FB, Twitter

    Zapraszamy do obserwowania taga #devfoundry ʕ•ᴥ•ʔ

    #programowanie #naukaprogramowania #java #it #programista #programista15k #devfoundryamista #programista15k #devfoundry

    •  

      @devfoundry a potem wychodzi ze szybciej napisać byle jaka implementację niż bawić się w mocki ( ͡º ͜ʖ͡º)

      +: uhu8
    •  

      @devfoundry: ooo właśnie obejrzałem stuby, oglądam dalej ;)

    •  

      @devfoundry: brzydko opisane - tak jakby ktoś nie umiał się wysłowić na ten temat, mialem oglądać ale jakoś chyba sobie odpuszczę (ʘ‿ʘ) sorki

      +: uhu8
    •  

      @Init0: Hej, dzięki za feedback. Będę wdzięczny za informację czy mówisz o wpisie na blogu czy filmie na youtube, i o którym fragmencie, bo jestem bardzo ciekawy co mógłbym poprawić.

    •  

      @devfoundry: wpis na blogu -> tekst czytam szybko a film jest spory. Zobaczę po pracy fragmenty to moze podeślę o ile znajdę czas.

    •  

      @devfoundry > które imitują zachowanie prawdziwych obiektów i prawdziwego kodu.
      A, czyli taki python na przykład? ( ͡° ͜ʖ ͡°)

    •  

      @devfoundry: Więc mniej więcej co mi sie nie spotobało.. budujesz bardzo wąskie analogie - ciągle sub i mock, mock i sub.. możesz porównać to do różnych innych rzecz np głupia analogia trochę do pokemona Ditto, który może zmienić się w coś innego i używać tych samych ataków co prawdziwy pokoemon - ale za to o ile prosciej:D Możesz oczywiście do czegoś innego

      I takiego mocka możemy teraz przekazać do konstruktora klasy AccountService:

      AccountRepository accountRepositoryMock = mock(AccountRepository.class);
      AccountService accountService = new AccountService(accountRepository); ->> chyba powinno być : accountRepositoryMock ?

      potem kod:
      private List<Account> prepareAccountData() {
      Address address1 = new Address("Kwiatowa", "33/5");
      Account account1 = new Account(address1);
      Account account2 = new Account();
      Address address2 = new Address("Piekarska", "12b");
      Account account3 = new Account(address2);
      return Arrays.asList(account1, account2, account3);
      }

      Jest lekko niefortunny, bo wracałem i sprawdzałem czy faktycznie stworzyłeś 3 konto i dlaczego sprawdzasz hasSizem 2 a nie 1

      Skoro to i tak funkcja testowowa, wtedy widać co tworzysz (oczywiscie to w celach nauki te zmienne):

      private List<Account> prepareAccountData() {
      Address PierwszyAdresPanaKowalskiego = new Address("Kwiatowa", "33/5");
      Account PierwszeKontoPanaKowalskiego = new Account(address1);

      Account PierwszeKontoPanaMareckiego = new Account();
      Address PierwszyAdressPanaMareckiego = new Address("Piekarska", "12b");
      Account DrugieKontoPanaMareckiego = new Account(address2); //Drugie konto, ale adress ten sam co wczesniej
      return Arrays.asList(account1, account2, account3);


      }

      Brzydko opisane, co mialem na myśli przykład:
      "Jeśli na przykład dana metoda zostanie wywołana na obiekcie mockowym z argumentem X, to mock ma zachować się tak, a jeśli z argumentem Y, to inaczej." - czytałem 2 razy xD

      Czy możemy powiedzieć że to mock się zachowuje?
      List<Account> accounts = prepareAccountData();
      AccountRepository accountRepository = mock(AccountRepository.class);
      AccountService accountService = new AccountService(accountRepository);
      given(accountRepository.getAllAccounts()).willReturn(accounts);

      Jak dla mnie to nie mock się zachowuje, a mock wpływa na obiekt/metode/funkcje która ma się zachować w określony (sprawdzany przez nas) sposób. Mock jest więc takim specjalnym narzędziem, który z małego sklepu, robi wielki magazyn. Zawsze będzie miał towar (o ile ma mieć towar - bo na to możemy wpłynąć), o którego poprosimy ;>

    •  

      @Init0: Hej, dzięki za obszerny feedback.

      Wydaje mi się, że takie przykłady i analogie są mocno subiektywne - jednej osobie spodoba się analogia z pokemonem, inna nie będzie miała zielonego pojęcia o co chodzi. Akurat w tym przypadku wydaje mi się, że nie ma sensu budowanie żadnych analogii, bo może to jeszcze bardziej namieszać, a koncept nie jest skomplikowany, jak na przykład w niektórych wzorcach projektowych gdzie analogie będą jak najbardziej na miejscu.

      Tutaj zamysł był bardzo prosty - pokazać najpierw jak wygląda kwestia poradzenia sobie z napisaniem testu, gdy nie mamy do dyspozycji mocków - stąd wpis o stubach. A drugi wpis już pokazuje jak wprowadzić mocki i z nich korzystać.

      Trochę zmodyfikowałem:
      "Jeśli na przykład dana metoda zostanie wywołana na obiekcie mockowym z argumentem X, to mock ma zachować się tak, a jeśli z argumentem Y, to inaczej." - czytałem 2 razy xD

      Ten fragment poprawiłem:
      AccountRepository accountRepositoryMock = mock(AccountRepository.class);
      AccountService accountService = new AccountService(accountRepository); ->> chyba powinno być : accountRepositoryMock ?
      Po prostu pisałem z palca, zamiast skopiować z projektu, stąd taka pomyłka.

      Co do adresów i kont, to problem bierze się pewnie z tego, że bardziej szczegółowo wyjaśniłem to w poprzednim wpisie - wkleję też do tego wpisu i poprawię żeby nie było wątpliwości.

      Rozumiem, że wpis nie przypadł Ci do gustu, postaram się z tego wyciągnąć wnioski i mam nadzieję, że następnym razem wyjdzie to lepiej ;)

      Dzięki za poświęcony czas :)

Gorące dyskusje ostatnie 12h

Advertisement