Poni\u017cej znajduje si\u0119 konfiguracja biblioteki:<\/p>\n\n\n\n Na pocz\u0105tku mo\u017cemy sobie zada\u0107 pytanie \u2013 po co w og\u00f3le s\u0105 nam potrzebne te testy? Na potrzeby artyku\u0142u napisali\u015bmy kod (dodany poni\u017cej), kt\u00f3ry s\u0142u\u017cy do pobierania lokalnego czasu w milisekundach. Mo\u017cemy by\u0107 przekonani, \u017ce jest on przygotowany poprawnie i zawsze b\u0119dzie dzia\u0142a\u0107.<\/p>\n\n\n\n I by\u0107 mo\u017ce tak rzeczywi\u015bcie b\u0119dzie, ale, b\u0119d\u0105c profesjonalistami, musimy upewni\u0107 si\u0119 podw\u00f3jnie, \u017ce nawet po edycji wszystko zadzieje si\u0119 tak, jak sobie to za\u0142o\u017cyli\u015bmy. W\u0142a\u015bnie dlatego powstaj\u0105 testy. <\/p>\n\n\n\n Aby zamockowa\u0107 nasz DateLocalSource, wykorzystujemy konstrukcj\u0119 mockk<typ obiektu> {}, gdzie w nawiasach klamrowych okre\u015blamy zachowania metod w danym obiekcie. Dzi\u0119ki s\u0142\u00f3wku kluczowemu \u201eevery\u201d, mo\u017cemy okre\u015bli\u0107, co dana metoda ma nam zwr\u00f3ci\u0107 w przypadku jej wywo\u0142ania. Osi\u0105gamy to w poni\u017cszym przyk\u0142adzie dzi\u0119ki s\u0142\u00f3wku kluczowym \u201ereturns\u201c, ale nie jest to jedyna opcja.<\/p>\n\n\n\n Je\u017celi chcemy zdefiniowa\u0107 bardziej zaawansowane zachowanie, oparte chocia\u017cby na argumentach przekazanych do metody, powinni\u015bmy u\u017cy\u0107 \u201eanswers\u201d, a gdy potrzebujemy, by ta metoda rzuca\u0142a nam wyj\u0105tkiem, wystarczy u\u017cy\u0107 \u201ethrows\u201d.<\/p>\n\n\n\n S\u0105 to podstawowe i najcz\u0119\u015bciej wyst\u0119puj\u0105ce s\u0142owa kluczowe, ale MockK oferuje ich znacznie wi\u0119cej. To niekt\u00f3re z nich:<\/p>\n\n\n\n Wiemy, jak zamockowa\u0107 to, co ma zwr\u00f3ci\u0107 dana metoda. Ale jak sprawdzi\u0107, czy w og\u00f3le ta metoda si\u0119 wywo\u0142a\u0142a? Z pomoc\u0105 przychodzi nam \u201everify\u201d. Wystarczy skorzysta\u0107 z konstrukcji verify { zamockowanyObiekt.metodaKt\u00f3rejWywo\u0142anieChcemySprawdzi\u0107() }, aby test przechodzi\u0142 tylko wtedy, gdy podana metoda zostanie wywo\u0142ana.<\/p>\n\n\n\n Warto pami\u0119ta\u0107, \u017ce gdy wykorzystujemy zwyk\u0142e \u201everify\u201d, to metoda musi zosta\u0107 wywo\u0142ana przynajmniej raz, by weryfikacja przebieg\u0142a pomy\u015blnie. U\u017cycie dodatkowych s\u0142\u00f3wek kluczowych u\u017cywanych w nawiasach \u2013 jak \u201eexactly\u201d \u2013 zostanie wyt\u0142umaczone w p\u00f3\u017aniejszej cz\u0119\u015bci artyku\u0142u.<\/p>\n\n\n\n Warto wspomnie\u0107 o jednej z wi\u0119kszych zalet biblioteki<\/strong>, a dok\u0142adniej o tym, \u017ce MockK wspiera jeden z filar\u00f3w j\u0119zyka Kotlin \u2013 korutyny<\/a>.<\/p>\n\n\n\n W przyk\u0142adowych testach naszego kodu do pobierania czasu ewidentnie wida\u0107, \u017ce metody typu \u201esuspend\u201d maj\u0105 osobny pakiet funkcji do mockowania oraz weryfikacji danych (przedrostek \u201eco\u201d). Dzi\u0119ki temu rozwi\u0105zaniu \u0142atwo da si\u0119 zauwa\u017cy\u0107, gdzie u\u017cywamy takiego typu metod, gdy\u017c z racji specyfiki budowy, wymagaj\u0105 one innego traktowania ni\u017c zwykle metody.<\/p>\n\n\n\n Nasuwa si\u0119 wi\u0119c wniosek:<\/strong> u\u017cywaj\u0105c MockK, nie musimy martwi\u0107 si\u0119 o metody \u201esuspend\u201d, poniewa\u017c wystarczy pami\u0119ta\u0107 o dodaniu przedrostka \u201eco\u201d, kt\u00f3ry pozwoli na ich bezproblemow\u0105 obs\u0142ug\u0119. <\/p>\n\n\n\n Pierwsz\u0105 bol\u0105czk\u0105, kt\u00f3ra b\u0119dzie wymaga\u0142a naszej decyzji, jest argument \u201erelaxed\u201d u\u017cywany przy definicji mockowanego obiektu. Biblioteka MockK domy\u015blnie NIE mockuje wszystkich metod danego obiektu. Ale w sumie jest to jej wielka zaleta! <\/p>\n\n\n\n Wyobra\u017amy sobie sytuacj\u0119, \u017ce tworzymy now\u0105 metod\u0119 zwracaj\u0105c\u0105 typ Unit i przez pomy\u0142k\u0119 umieszczamy j\u0105 w miejscu, w kt\u00f3rym nie powinno jej by\u0107. W takim przypadku u\u017cycie \u201erelaxed = True\u201d spowoduje, \u017ce test nie b\u0119dzie w stanie wykry\u0107 nieprawid\u0142owo\u015bci, gdy\u017c metoda b\u0119dzie automatycznie zamockowana. <\/p>\n\n\n\n W ka\u017cdej innej sytuacji r\u0119czne wpisane ka\u017cdego \u201eevery\u201d b\u0105d\u017a \u201ecoEvery\u201d dla naszych metod zabezpieczy nas, poniewa\u017c ka\u017cda niezamockowana metoda zwr\u00f3ci b\u0142\u0105d testu. Z tego powodu uwa\u017camy, \u017ce powinni\u015bmy u\u017cywa\u0107 tego argumentu z g\u0142ow\u0105 i tylko w przypadku ch\u0119ci przetestowania konkretnych sytuacji, gdzie nie zwracamy uwagi na inne metody.<\/p>\n\n\n\n \u201eVerify\u201d dzi\u0119ki mo\u017cliwo\u015bci podania argument\u00f3w jest bardzo elastycznym narz\u0119dziem do weryfikacji wywo\u0142a\u0144 metod. Oto najcz\u0119\u015bciej wykorzystywane:<\/p>\n\n\n\n MockK oferuje nam jeszcze dodatkowe opcje weryfikowania, kt\u00f3re zosta\u0142y przedstawione na przyk\u0142adach poni\u017cej.<\/p>\n\n\n\n <\/p>\n\n\n\n Statyczne metody to byt, kt\u00f3ry wywo\u0142uje mieszanie uczucia. Nale\u017cy si\u0119 jednak zgodzi\u0107, \u017ce s\u0105 momenty, w kt\u00f3rych jest to ca\u0142kiem przydatne rozwi\u0105zanie. Dlatego wydaje si\u0119 rozs\u0105dne, \u017ce biblioteka MockK postanowi\u0142a domy\u015blnie wesprze\u0107 ten spos\u00f3b pisania kodu.<\/p>\n\n\n\n <\/p>\n\n\n\n We wskazanym przyk\u0142adzie pomy\u015blnie zamockowalismy statyczn\u0105 metod\u0119 \u201egetInstance()\u201d b\u0119d\u0105c\u0105 cz\u0119\u015bci\u0105 klasy Calendar. Gdy ju\u017c jej nie potrzebujemy, u\u017cywamy metody \u201eunmockkStatic(Calendar::class)\u201d, kt\u00f3ra cofa zamockowanie klasy.<\/p>\n\n\n\n Czy z architektonicznego punktu widzenia powinno testowa\u0107 si\u0119 dzia\u0142anie\/wywo\u0142anie prywatnych metod? To r\u00f3wnie\u017c kwestia sporna i zale\u017cna od sytuacji.<\/p>\n\n\n\n Niemniej, bardzo dobrze, \u017ce MockK tak\u017ce wspiera to rozwi\u0105zanie i nie wymaga przy tym adnotacji @VisibleForTesting. Wystarczy u\u017cy\u0107 spyka z parametrem \u201erecordPrivateCalls\u201d ustawionym na \u201etrue\u201d, co umo\u017cliwi nam zamockowanie prywatnej metody w spos\u00f3b pokazany poni\u017cej.<\/p>\n\n\n\n O spyku nale\u017cy jednak napisa\u0107 nieco wi\u0119cej, gdy\u017c to rozwi\u0105zanie daje nam du\u017ce pole manewru. W domy\u015ble operujemy na realnym obiekcie, a nie jego mocku, przy czym w dalszym ci\u0105gu mo\u017cemy cze\u015b\u0107 metod zamockowa\u0107, podczas gdy reszta b\u0119dzie operowa\u0142a na realnym kodzie.<\/p>\n\n\n\n Cz\u0119\u015b\u0107 os\u00f3b mo\u017ce zapyta\u0107, czym jest w og\u00f3le Mockito. Mockito to biblioteka, kt\u00f3ra tak jak MockK umo\u017cliwia testowanie, z t\u0105 r\u00f3\u017cnic\u0105, \u017ce stosuje ona bardziej klasyczn\u0105 sk\u0142adni\u0119 Javy, co dla niekt\u00f3rych mo\u017ce by\u0107 minusem. Szczeg\u00f3lnie, gdy na co dzie\u0144 pisz\u0105 w Kotlinie. W takim przypadku sk\u0142adnia MockK powinna im bardziej przypa\u015b\u0107 do gustu, poniewa\u017c jest bardzo podobna do tej u\u017cywanej w j\u0119zyku Kotlin.<\/p>\n\n\n\n Co szczeg\u00f3lnie przemawia na rzecz u\u017cywania MockK zamiast Mockito? Argumenty przedstawimy w formie tabelki.<\/p>\n\n\n\n![\"Konfiguracja](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/06\/1-1.png\")
<\/a>Po co testowa\u0107?<\/strong> <\/h2>\n\n\n\n
<\/a><\/figure>\n\n\n\nJak testowa\u0107 z u\u017cyciem biblioteki MockK?<\/strong><\/h2>\n\n\n\n
<\/a><\/figure>\n\n\n\n\n
Jak sprawdzi\u0107, czy metoda si\u0119 wywo\u0142a\u0142a?<\/strong><\/h3>\n\n\n\n
<\/a><\/figure>\n\n\n\nKorutyny<\/strong><\/h3>\n\n\n\n
Domy\u015blnie czy niedomy\u015blnie?<\/strong><\/h2>\n\n\n\n
<\/a><\/figure>\n\n\n\nNie tylko prosta weryfikacja<\/strong><\/h2>\n\n\n\n
\n
<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\n\n
A co z metodami statycznymi?<\/strong><\/h2>\n\n\n\n
<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\nSpos\u00f3b na prywatne metody?<\/strong><\/h2>\n\n\n\n
<\/a><\/figure>\n\n\n\n\n
MockK czy Mockito?<\/strong><\/h2>\n\n\n\n