00:00:00: Music.

00:00:06: Witaj w drugim odcinku Szkoła Androida to podcast w którym opowiadam o tworzeniu aplikacji.

00:00:13: Wraz z moimi gośćmi rozmawiał tym jak budować aplikację pomijając o architekturze bezp.

00:00:19: Nazywam się Sylwester Madej i o 10 lat sam tworzy aplikacje mobilne oraz prowadzę szkolenia gdzie uczą innych programistów Jak robić.

00:00:29: Dzisiejszy odcinek będzie trochę nietypowy nie będzie gościa natomiast chciałem pokazać prezentację z konferencji for developers

00:00:39: opowiadałem o roli screenshot Uf w testach i łojowych i o tym jak wyglądała ewolucja mojego podejścia do testów.

00:00:48: Zapraszam przede wszystkim do oglądania tego w wersji wideo na szkoła Androida pl ukośnik.

00:00:58: Ponieważ będzie tutaj nie.

00:01:01: Rzeczy wizualnych natomiast Jak najbardziej można to także posłuchać w wersji audio Dlaczego taki zapracowany.

00:01:09: Cześć tak jak już powiedziałem dzisiaj porozmawiamy sobie o testach i o tym jak screenshoty mogą w testach uczestniczyć taką historię o to

00:01:23: udało mi się.

00:01:24: Pisanie testów i łojowych przekształci ze znanego obowiązku a zadanie które może nawet zrobić Junior i to jeszcze nawet mając z tego jakąś przyjemność i będzie to w postaci historii mojej ewolucji

00:01:39: mojego podejścia do testów i tego jaką rolę właśnie testy screenshota odgrywają w tym całym Podaj.

00:01:46: I zaczniemy to całą historię niedawno temu w pewnym projekcie aplikacji na.

00:01:52: Sklep Google Play jest zalewany przez masę aplikacji które powstały bez napisania nawet.

00:01:58: Ich użytkownicy traktowani są jako testerzy manualnia konsola fairways jako centrum

00:02:04: nasz bohater postanowił poprawić jakość aplikacji dodając testy automatyczne niestety testy i y okażą się być wymagającym są już nie.

00:02:13: Poznajemy naszego bohatera w tym przypadku będę to ja

00:02:19: w Androidzie Siedzę już od 2011 i w tej chwili głównie skupiłem się właśnie na tych trzech filarach na bezpieczeństwie na testach i na architekturze aplikacji które są ze sobą powiązane prowadzę szkolenia 2014 i

00:02:37: od jakiegoś czasu prowadzę też bloga YouTube i podcast

00:02:42: podcast jest nowa rzecz którą dopiero co zacząłem gdzie będę rozmawiał z ludźmi z branży O właśnie różnych ciekawych rzeczach które można wdrożyć do swoich.

00:02:52: It

00:02:54: całą historię zaczniemy a w mrocznych czasach Gdy wielkość ekranu określa się jako Fill Parent były to czasy kiedy

00:03:04: Activity było tak naprawdę gad obiektem i większość kodu lądował o w tym Activity nikt nie myślał jeszcze architektura w nikt nie myślał jakiś szczególnych warstw.

00:03:14: W większości projektów androidowych te testy jednostkowe nie istniał.

00:03:19: Głównie ze względu na to że były problemy z biblioteką Androida czyli z Android kropka.

00:03:25: A gdzie wszystko było po mocowane po zaślepiony i Final w związku z tym nie można tego

00:03:31: A nic sensowny sposób zamocować ani też inne w jakiś sposób testować i w tych czasach

00:03:39: testy praktycznie nie istniały Jedyne co mieliśmy

00:03:43: co mogliśmy zrobić to spotkać się z wielkim testem instrumentacji innym czyli

00:03:50: jedynym sposobem który był dostępny od samego początku niestety testy instrument acyjne mają jedną podstawową wadę działają tylko na urządzeniach albo emulatorach Co oznacza że są bardzo vol.

00:04:04: I co oznacza że są trochę złym pomysłem na to jeżeli Chcemy przetestować po prostu kawałek logiki.

00:04:12: Natomiast Sprawdzają się jeżeli Chcemy przetestować interfejs użytkownika i to tak naprawdę jest jedyny sensowny sposób na to żeby przetestować interfejs użytkownika

00:04:22: po to żeby zobaczyć jak nasz ekran będzie wyglądał w określonej sytuacji a po to żeby sprawdzić czy te elementy które wyświetla mi użytkownikowi wyglądają odpowiednio zachowują tak

00:04:35: natomiast niestety.

00:04:39: Deweloperzy mieli zwykle doświadczenie z na przykład wrzawy z projektem Zawodowych w związku z tym próbowali

00:04:48: Ja też w próbowaliśmy w różny sposób te testy jednostkowe przemycać po to żeby móc jednak logikę w naszych aplikacjach testować i to się głównie sprowadzało do tego że przez jakiś czas nie było oficjalnego wsparcia

00:05:02: Google korzystaliśmy z rozwiązań takich jak właśnie hakowanie w projekcie mivena czy dodawanie moich Bena po to żeby móc te testy odpalać.

00:05:13: Dzięki temu można było napisać nieco jakiś testów jednostkowych

00:05:17: jednak Wtedy jeszcze nie było aż tak mocno rozwinięty wszystkich podejść architektonicznych więc ale zwykle test jednostkowe służyły do testowania

00:05:26: różnego rodzaju jakiś funkcji z logikon bibliotek utils owych typu jakiś formatowanie obsługa daty i tego typu rzeczy.

00:05:36: Potem pojawił się robolectric nie wiem

00:05:41: ilu z was jeszcze pamięta robolectric a obecnie mam trochę przeżywa tak jakby renesans ponieważ Google oficjalnie zaczął go wspierać natomiast przez pewien czas robolectric był taki.

00:05:52: Takim projektem wewnętrznym O ile pamiętam firmie pivotal który powstał po to żeby właśnie zastąpić tego nieszczęsnego Android gara

00:06:01: i umożliwić ludziom testowanie rzeczy takich na styku Androida i logiki czyli na przykład tego jak są archisorte obsługiwane czy jakiś Stringi są wyciągane wychowujących życia fragmenty tych życia Activity i tak dalej

00:06:17: niestety robolectric miał jedną wadę podstawową był

00:06:22: bardzo niestabilny i wymagał zwykle dużo czasu po to żeby chce katować go w projekcie atesty które wykorzystywały robolectric a miały tą tendencję.

00:06:33: Zaczynały testować implementację Androida i zamiast testować logikę aplikacji testował o się toczy jeże

00:06:41: wyciągnę jakiś string to czy się wyświetli ten string odpowiednimi

00:06:45: to było Nie trochę te składało do testowania nie tego co potrzeba Natomiast w pewnym momencie umożliwiały między innymi takie rzeczy jak podejście powiedzmy test Driven Development

00:06:58: do tworzenia kodu Android owego to była rzecz która na pewno dawała jakieś takie poczucie tego że jednak testy jednostkowe da się pisać.

00:07:08: Po wielu latach Imperium Google postanowiło dać nam narzędzia do testowania głównie do testów i y owych wprowadzając przede wszystkim espresso i Espresso taka biblioteka która pozwala.

00:07:23: Tworzyć

00:07:24: testy Iława dużo łatwiej niż do tej pory bo do tej pory trzeba było korzystać z jakiś zewnętrznych bibliotek żeby na przykład asercje robić na interfejsie użytkownika mieliśmy łatwy sposób na to żeby robić akcje żeby robić asercje żeby sprawdzać czy dany się wyświetlają

00:07:43: wprowadzać dane i tak dalej niestety

00:07:47: testy nadal to są testy instrument acyjne w związku z tym testem wykorzystujące Espresso są wolne chociaż

00:07:55: W pewnych sytuacjach da się tworzyć tak jakby testy testujące logikę przy użyciu także Espresso Czy jeżeli wprowadzę jakieś dane do pól tekstowych nacisnę przycisk to chcę zobaczyć czy Wyświetli się wodpol informacje dane albo czy zostanie wykonany jakiś tam z zapyta

00:08:11: więc to skłoniło trochę do prowadzenia to ci te

00:08:15: integracyjnych w warstwie u i powiedzmy tutaj jeszcze wady tego Espresso to właśnie to że jest ta taka składnia Hang

00:08:25: która jest dosyć męcząca i przykładowo

00:08:27: kliknięcie sprawdzenie czy jakiś tam widok jest widoczny No to tak naprawdę trzeba robić jakieś tam on Vita

00:08:35: podać i dziczek matches isdisplayed to powoduje że jeżeli

00:08:41: Dużo mamy takich fragmentów z dużo tych ma czarów dużo linijek w ramach testu to test staje się bardzo nieczytelne Ale o tym jeszcze opowiem jak to później.

00:08:52: Natomiast czasem też trzeba napisać jakiś własny matcher albo jakąś własną akcję żeby na przykład wykonać akcje na recycling.

00:09:02: Albo zrobić jakieś nietypowe scrollowanie do konkretnej pozycji na ekranie i tak dalej i tak dalej jest jest trochę rzeczy które

00:09:11: jeżeli projekt odpowiednio długo się przy użyciu Espresso testuję to prawdopodobnie i rośnie taka biblioteka własnych właśnie maczer własnych akcji po to żeby testować te rzeczy które standardowo

00:09:22: się w tym projekcie powtarzają i teraz kolejną rzeczą

00:09:28: która sprawiała że te testy miał jakikolwiek sens te testy integracyjne w oparciu Espresso to jest som oki czyli konieczne było mocowanie

00:09:38: różnych warstw zwykle to były warstwy danych

00:09:43: po to żeby uzyskać szybkie i stabilne test bo jeżeli nie daj Boże mielibyśmy sytuację w której nasze testy faktycznie uderzają do API ale to teraz te testy mogłyby działać kilka kilka sekund powiedzmy na jeden test byłyby super niestabilne i

00:09:59: tak naprawdę nie mielibyśmy pewności że za każdym razem kiedy je puścimy odpalam się i datą taki sam rezultat bo mimo że po drodze akurat nasze API testowe jest.

00:10:12: Nieaktualne w czasie aktualizacji albo coś w tym stylu.

00:10:17: Takim rozwiązaniem które zwykle się stosowało w tego typu testach jest podejście w którym bierzemy interface retrofit owe mocujemy je na przykład przy użyciu Mohito

00:10:26: i ustalamy że zwraca to konkretny obiekt.

00:10:31: Zwykle to był taki obiekt typu poszło albo epoką mam Czyli po prostu zwykły obiekt.

00:10:39: Taki Java Bean i ten obiekt wracaliśmy dziś Czemu mieliśmy pełną stuprocentową pewność że za każdym razem dostaniemy te dane Wiedzieliśmy jak te dane będą wyglądały

00:10:49: to miało jedną wadę ponieważ tak naprawdę nie mieliśmy ale nie schodziliśmy poniżej pewnej warstwy czy nie schodziliśmy Poniżej tej warstwy Komunikacji danych czyli na przykład nie robiliśmy pomiędzy tymi obiektami a

00:11:04: iPhonami które przychodzą zapina to czasami nie jest nie jest oczywiste bo tam czasami jakieś specjalne napary mogą być wymaz.

00:11:14: I takie podejście z tego typu testami integracyjnymi czy testami gdzie Espresso tak naprawdę pozwalało nam przed S

00:11:22: wszystkie warstwy aplikacji powiedzmy aż do tego a picie do jakiejś tam zablokowanej bazy danych sprawdzało się dosyć dobrze przez dłuższy czas Ja na przykład jeszcze w zeszłym roku stając tego w projekcie i oczywiście to ma swoje zalety bo ten sposób da się dosyć łatwo

00:11:41: przetestować całą aplikacje

00:11:44: tak jak mówię do do pewnej warstwy jeżeli korzysta się z łóżka z dependency injection a wtedy możemy sobie wstrzyknąć zamiast normalnego retrofit który uderza do API wstrzykujemy po prostu zaślepkę retrofit

00:11:56: która zwraca zahardkodowane odpowiedź.

00:12:00: Podejście którym Testujemy właśnie w ten sposób czyli Testujemy od od strony użytkownika

00:12:09: nasz test wpisuję jakieś dane klika i tam powiedzmy wychodzi jakiś API Można testować nawet jeżeli Nasza aplikacja nie marchwi

00:12:17: Czyli jeżeli to jest Aplikacja napisana w postaci jednego God obiektu gdzie wszystko jest dostępne to Jeżeli jesteśmy tylko w stanie na przykład zaślepić colę do API to możemy całą noc testować ponieważ tutaj nie ma

00:12:31: tak naprawdę konieczności testowania konkretnych warstw tylko możemy przetestować całą aplikacje.

00:12:39: W tym podejściu nawet udało mi się robi.

00:12:45: Namiastkę takich od test Driven Development czyli sytuacja w której jeżeli wiem jak ten ekran ma wyglądać i co ma robić to zaczynam od tego że tworzę sobie ekran Pierwszy mój test zdanie wyświetlić pusty ekran i potem tworzy kolejny test w którym mówię że

00:13:03: teraz prowadzę dane i zakładam że uderzy mi do a p i w ten sposób mogę najpierw napisać test a potem zacząć pisać kot którego na końcu uderzył mi do

00:13:12: to jest bardziej podejście takie nawet bdd czyli takie behavior Driven Development niż tdd ponieważ operujemy na takim dosyć

00:13:20: wysokim poziomie nie jesteśmy w stanie zejść w same poszczególne małe komponenty tylko już od takiej perspektywy użytkownika czy jako Użytkownik wpisuje jakiś danych klikam przycisk i powinienem widzieć

00:13:33: więc to są to są takie zalety które to daje.

00:13:36: Niestety im dłużej w projekt chodziłem im dłużej korzystałem z tego w projektach to tym bardziej widziałem że są też wady

00:13:45: przede wszystkim te testy są wolne i tutaj

00:13:51: powyżej nie da się uzyskać sensownego pokrycia całego kodu testami ponieważ

00:13:58: każdy kolejny test dokłada kilkaset milisekund może nawet czasami sekundy do tego długości trwania tego skrótu który za każdym razem trzeba odpalić To powodowało z w ramach jednego testu w ramach jednej takiej funkcji testującej umieszcza liśmy kilka asercji po to żeby jak najwięcej rzeczy być w stanie przy użyciu takiego jednego testu sprawdź

00:14:21: po to żeby nie czekać znowu aż się odpali kolejny test ich kolejnym teście z robić jakąś kolejną ofertę tylko jeżeli to są

00:14:29: podobne rzeczy zakładając na przykład te same dane wejściowe to robiliśmy wiele Asertin

00:14:36: takie podejście zwykle w testach prowadzi do tego że trudno jest debugowanie aplikanta Czy trudno jest tak naprawdę w momencie failu określić dlaczego test się wyda

00:14:47: i wtedy zwykle to się sprowadza do tego że trzeba było gdzieś tam jakimś podpiąć się do bageren po to żeby sprawdzić co faktycznie zaszło źle

00:14:57: ten konkretny a funkcja testująca ten konkretny test się wywal.

00:15:02: No i to zdecydowanie utrudnia takie szybkie reagowanie.

00:15:08: I też często To zależy oczywiście od aplikacji ale często jest tak że aplikację mają jakiś swój stan czyli mają na przykład jakąś bazę danych mają jakiś sesję którą muszą przechowywać iru komponenty

00:15:22: które trzeba też pomalować po to żeby odpalić jakikolwiek stan czyli w momencie kiedy mieliśmy na przykład aplikację która

00:15:29: na początku musiała sprawdzić czy aktualnie użytkownik jest zalogowany wchodząc na konkretne ekran to Pierwszą rzeczą którą musieliśmy zrobić to jest Zamkowa nie że tak użytkownik jest zalogowany i dopiero wtedy wyświetlić ten konkretny.

00:15:43: Także to wymagało dodatkowej pracy i utrudniało wejście w każdy nowy

00:15:48: ponieważ sąd napisać test dla nowego ekranu trzeba najpierw było zamontować te wszystkie rzeczy ten cały stan który potrzebowaliśmy w konkretnym na konkretnym.

00:16:00: To też powodowało że ciężko było uzyskać takie stabilne testy które wiedzieliśmy że

00:16:07: będąc w stu procentach powtarzalne ponieważ Im więcej na przykład też ekranów przechodziliśmy tym była większa szansa że na przykład przechodząc z ekranu a do ekranu B do ekranu c na którym z nich a za dzieje się jakaś sytuacja w której nie przewidzieliśmy

00:16:21: i będziemy mieli problem A potem jakiekolwiek zmiany oznaczały nawet na poziomie interfejs użytkownika oznaczały że musimy zmienić wszystkie ekrany które to interfejs użytkownika dotyka

00:16:35: wszystkie testy które danego ekranu dotyk.

00:16:39: No i niestety to prowadzi do do tej brzydkiej strony tych testów i do nas ten które To powodowało czyli przede wszystkim to że testy były niestabilne powodował że trzeba było tak dużo pracy włożyć żeby napisać nowy test powodowało że ma

00:16:55: osób w zespole było chętnych do tego żeby dodawać nowe testy i pracować nad tym żeby poprawić pobrać na plik

00:17:04: ponieważ za każdym razem kiedy ktoś robi jakiś nowy ficzer to musiał teraz usiąść zrobić znowu setup ustawić wszystkie rzeczy przygotować i dopiero wtedy mógł zacząć tak naprawdę.

00:17:17: Powiedz gesty Zwłaszcza jeżeli testy dopisywało się już dla istnieją

00:17:22: kodu czyli w tym podejściu DDD było trochę łatwiej w podejściu w którym ktoś miał napisał cały kot i miał go przetestować miał napisać te

00:17:32: tak naprawdę nie mógł przetestować miał napisać testy do tego kodu to był to duży nakład pracy.

00:17:38: I To powodowało też że jeżeli testy były nie do końca stabilne to coraz więcej tych test

00:17:45: w przypadku gdy były na przykład zależności pomiędzy testami zaczynamy lądować jako at ignor czyli były po prostu ignorowane i wylądowały tak naprawdę ze suit a To powodowało że były takie małe które

00:17:58: których wartość była zerowa tylko zajmowały miejsce w.

00:18:03: I i to trwało przez dłuższy czas ponieważ

00:18:09: takie podejście jeżeli już się człowiek czegoś nauczy to niestety strefa komfortu wciąga i ciężko jest wyjść poza tą strefę komfortu też dosyć łatwo się takie testy pisze ponieważ nie trzeba Po pierwsze nie trzeba mieć jakieś super architektury po drugie nie Trzeba też myśleć o tym

00:18:26: jak w konkretne rzeczy przetestować

00:18:29: a dosyć łatwo jest zrobić coś pod tytułem wpisuje dany wpisuję dane klikam i sprawdzam wynik natomiast

00:18:37: nie zawsze takie podejście ma sens czy nie zawsze to podejście który się napisze testy klikające ona tak naprawdę niewiele testuję jeśli chodzi o logikę aplikacje bardziej testuje czy że pojawiają na ekranie.

00:18:50: I to często też prowadzi do sytuacji w której Jeżeli mamy takie testy i nauczyliśmy się już pisać takie testy to zaczynamy t t y traktować jako testy jednostkowe i na przykład chcąc czy przetestować jakąś logikę przetestować ją jako po prostu kawałek

00:19:04: kodu który w separacji możemy bardzo łatwo przetestować testowaliśmy w ramach takiego testu integracyjnego co powodowało że

00:19:12: nie oczywiście to się dużo wolniej odpalało niż moglibyśmy mieć to w przypadku testu unit ovako na szczęście a spotkałem swojego jodem który powiedział mi że jemy albo testujemy

00:19:26: albo tak naprawdę ale Testujemy już nie ma trzeciej drogi.

00:19:32: I w tym przypadku to dzięki Dla Andrzeja pokazał mi coś takiego

00:19:38: czyli taki tok o tym że te testy integracyjne są

00:19:45: o 6:00 tańczy w momencie kiedy próbujemy wstać testy integracyjne czy zakładamy że napiszemy jeden test który przetestuje nam wiele warstw to niestety doprowadzamy do sytuacji w której.

00:19:58: Testuję dużo trudniej jest przetestować jakiś większy zakres ale to jest swoją drogą prezentacja JBL w Bergen obejrzeć Bardzo fajnie to pokazuje jak tak naprawdę testowanie jednostkowe jest

00:20:16: dużo

00:20:17: tańsze ponieważ dużo łatwiej jest przetestować pojedynczy element w separacji przetestować jego wszystkie zakamarki i przejść do następnego niż próbować z perspektywy na przykład użytku testować wszystkie warstwy pod spodem bo wtedy niestety im więcej tego poziomu w zagłębienia

00:20:34: więcej musielibyśmy napisać testów żeby sprawdzić wszystkie te zagłębienia.

00:20:42: Dlatego też Postanowiliśmy zmienić trochę podejście i pojawił się pomysł na lepsze i najlżejsze testy i majowe czyli na na to żeby testy i o wszystkim decydowały tylko warstwę

00:20:57: Czyli już w tej chwili mamy zabronione żeby testować jakąkolwiek logikę

00:21:01: testy i majowe mają tylko i wyłącznie na celu przetestować tą najwyższą warstwę warstwę prezentacji czyli to jak jak działa databinding bo akurat używaliśmy databindingutil

00:21:14: czy fragment wszystko dobrze

00:21:17: Czyli jeżeli ustawimy konkretne dane do wyświetlenia to czy te dane się wyświetlają w taki sposób jaki byśmy zakładali wszystko poniżej tego

00:21:25: jesteśmy w stanie przetestować jednostkowo ponieważ to jest kot zwykle czysto kostninowy i A gdzie nie ma nie ma jakieś rzeczy.

00:21:35: Nie ma takich rzeczy związanych z Androidem i tutaj kluczem do tego żeby uzyskać te stabilne testy i łojowe jest to żeby zamontować sobie

00:21:45: do danego fragmentu przecież nie mamy fragment ona swój View Model ten v-modelist połączony z naszym do tabeli linkiem to robimy coś takiego

00:21:54: mocujemy cały model i przygotowujemy go w ten sposób żeby żebyśmy byli w stanie dowolny View Street

00:22:02: Czyli mamy tak jakby zbiór wszystkich danych które są aktualnie wyświetlane na ekranie

00:22:06: postaci takiego obiektów justay i ten obiekt biust a jesteśmy w stanie bardzo łatwo dowolny ustawić i Dzięki czemu możemy zamówić

00:22:16: dowolny

00:22:18: dowolny wygląd aplikacji dowolny stan aplikacji z perspektywy i olejowej możemy zablokować ponieważ zawsze to jest po prostu jeden obiekt który Musimy ustawić na nim odpowiednie wartości kazać do v-model

00:22:31: evie Model ten zamocowany v-model ale spowoduje że on się wyświetli na ekranie i wtedy mamy stabilne tak jak.

00:22:39: Wygląd ekranu i naszym celem nie jest testowanie tego Czy jak wpisze coś tam i kliknę to czy to działa coś tylko tak naprawdę przetestowanie tego czy jak ustawię odpowiednie dane na nasze

00:22:51: to wyświetlam się w odpowiedni sposób na ekranie i ewentualnie Jeżeli może jeszcze możemy testować jak na przykład pisze Jakiś danej fitness

00:22:59: to czy te dane i ten przycisk zostaną przekazany do odpowiedniej Med

00:23:04: I to tak naprawdę jesteśmy w stanie bardzo łatwo przetestować a później już całą logikę zakładając że wiemy że View model dostaje

00:23:12: takie dane i wywołanie takiej metody to jesteśmy w stanie bardzo prosto Junikowo już sobie.

00:23:20: Ważnym składnikiem tego żeby żeby to się udało

00:23:25: podejście Clean architecture tutaj już nie będę wchodził w Takie szczegóły Clean architecture bo mam nadzieję że większość a tutaj osób które to oglądają ma pojęcia architekt Czyli jeżeli nie to bardzo polecam Zwłaszcza jeżeli.

00:23:39: Macie chęć na to żeby testować swój

00:23:42: No chyba że jesteście w obozie tych którzy zakładają że użytkownicy w Google Play ufam przetestują bo tak też można Natomiast

00:23:51: dobra architektura równa się łatwe testy jednostkowe ponieważ szpinak i tak czy mamy tą jasną separację warstw Czyli każda warstwa to warstwa domeny czy to warstwa prezentacji i tak dalej

00:24:05: one mają sam od siebie odseparowane Mamy interfejsy które to.

00:24:10: Mocno se parują i wtedy bardzo łatwo możemy powiedzieć że okej w tej chwili Testuję tylko warstwę na przykład domeny tylko już Case

00:24:19: dzięki temu bardzo prosto piszemy szybkie szybkie proste testy unit owe jesteśmy w stanie uzyskać

00:24:25: blisko 100% kobiet rzeczywiście stuprocentowy Cover dla 100% dobry czy nie.

00:24:31: Celem samym w sobie ale warto czasami warto czasami jednak przetestować bo tak naprawdę jeżeli Testujemy to im bardziej Testujemy tym bardziej coś tego co wypuszczamy do klient.

00:24:46: I tutaj właśnie w tej architekturze i often Clean architecture jest to warstwa tak zwany framework Drive

00:24:53: ewentualnie z presentation i to są warstwy które odpowiadają za to za komunikację tak naprawdę ten najniższy poziom czy to poziom komunikacji pomiędzy użytkownikiem faktycznie już ekran obsługa przycisków i tak dalej

00:25:09: ewentualnie to warstwa dostępu do danych jakiś dostęp do GPS i tak dalej ale tych rzeczy nie jesteśmy w stanie zwykle Julii to go przetestować ponieważ wymagałoby to posiadania faktyczne system stacyjnego

00:25:22: i wtedy.

00:25:23: Testujemy to na urządzeniu do tego właśnie testy czy to takie testy i łojowe czy to testy integracyjne testując jakieś konkretne rzeczy na urządzeniu się przydaje.

00:25:35: Tutaj jeszcze warto porozmawiać o tej warstwie do takiego prezentacji.

00:25:43: Powiedziałem że korzystamy z modelu i tutaj korzystamy z takiego podejścia gdzie mamy View model który jest

00:25:53: dosyć 300 kabinowy oczywiście tam może mogą się na przykład zdarzać r kropka it kropka coś tam albo i kropka Sting kropka coś tam natomiast nie korzystamy z jakichkolwiek rzeczy typu fragment.

00:26:07: Dostęp getstring i tak dalej.

00:26:11: Tutaj zakładamy że tą całą cały film model da się przetestować przy użyciu jointa przy użyciu testów u nitowych mamy.

00:26:22: Maja coś takiego że mamy jeden Live dt1 live.it która emituje View State jeden obiekt który jest niezmienny

00:26:30: jeżeli chcemy dokonać jakiekolwiek zmiany w interfejsie użytkownika to musimy zrobić kopię tego obiektu zmienić sobie konkretną wartość

00:26:40: nowy obiekt a niemodyfikowany obiektu trochę upraszcza kwestie jeśli chodzi o kwestie synchronizacji i tak dalej

00:26:51: więc mamy jeden obiekt który mamy całą reprezentację tego co będzie na ekranie.

00:26:56: I data Binding mam założenie że databinding ma za zadanie tylko i wyłącznie wyświetla

00:27:05: dane które są z wystawy to przekazane czyli dostaję od

00:27:09: ma tylko wyświetlić Nie zawiera jakiejkolwiek logiki może poza jakimś najprostszym może poza kimś najprostszym nie wiem.

00:27:19: Parsowanie drinka czy nie pasowaniu stringów tylko robieniem free templates Czyli jeżeli potrzebujemy gdzieś przekazać jakiś string plus jakąś tam wartość tego zrobić sklejkę to takie rzeczy Mogą jeszcze być ale jeżeli jakiegoś enda albo jakiegoś

00:27:33: to raczej nie powinno się tam znajdować ale tylko powinno być jakimś miejscu gdzie to da się przetestować.

00:27:40: I tutaj pozostało nam popracować nad czytelność on testów i ty posłuchałem oczywiście Jake naszego Andrzejka Ordona który który nie jedną rzecz w Androidzie poprawił

00:27:51: idzie Kiedyś opowiadał o czymś takim jak robot pattern to jest też znany jako Page Object pattern koncepcja jest dosyć prosta że tak naprawdę konkretne ekran na naszym naszym teście w naszej aplikacji ma ze sobą powiązane taki

00:28:09: obiekt który wie W jaki sposób wykonać różne akcje lub różne kroki na nim czyli zamiast

00:28:17: to co Pokazywałem wcześniej jeśli chodzi o Espresso czytam on View check isdisplayed to możemy mieć po prostu metodę która się nazywa jak taki krok wewnątrz tego robota który się nazywa check.

00:28:30: Baton isdisplayed na przykład

00:28:33: tych kroków możemy sobie zrobić kilka to sprawdza że to sprawia że nasze testy nie zawierają już ani jednego odwołania do

00:28:40: Espresso ponieważ testy składają się tylko i wyłącznie z Robotów Czyli mamy taki obiekt robota i na tym obiekcie robota wykonujemy poszczególne kroki test.

00:28:50: Dzięki temu nie musimy nie musimy tych tych kroków

00:28:56: jakby patrzeć na implementację tylko patrzymy na to w teście to faktycznie ten test testuję czyli sprawdzamy Jaka jest logika która się znajduje za tym co chcemy aktualnie

00:29:10: tak jak mówiłem oddziela logikę testów od ich implementacji i tutaj tak naprawdę gdybyśmy się uparli postanowili zmienić z espresso na jakąś inną bibliotekę to równie dobrze moglibyśmy po prostu podmienić implementacje tych kroków w robotach a zostałyby nadal nam całe testy

00:29:27: testy składają się z tych.

00:29:29: Tutaj możemy sobie nadawać czytelne nazwy dla kroków czyli dużo bardziej zwiększać czytelność tych testów

00:29:38: ja osobiście polecam takie coś jak Live template Gdzie można sobie w Android Studio zrobić szablon w którym Jak tworzymy nowy test to po prostu generuje nam się test Plus z nim

00:29:51: odpowiedni nazwy odpowiednie jakiś tam metody które są potrzebne wszystko możemy sobie wygenerować właśnie przy użyciu takiego template tam i wtedy

00:30:00: oszczędza dużo czasu i też zmniejsza tak jakby nakład pracy potrzebne na to żeby stworzyć nowy test dla ekranu na przykład który jeszcze nie ich.

00:30:12: Okej druga jeszcze kwestia jeśli chodzi o roboty to jest to że można współdzielić kroki i tutaj Po pierwsze jak mamy robota to możemy kroki z tego robota używać w wielu testach Czyli mam natka 10 testów

00:30:24: podobne rzeczy na przykład mam ekran logowania powiązanego z nim robota i w ramach tego jednego ekranu logowania chcemy sprawdzić czy się uda zalogować Jeżeli nie wpisze danych to czy się nie uda zalogować cipo jakiś i tak

00:30:37: Większość z tych testów będzie miała na przykład metodę kliknij przycisk zaloguj i ten kliknij przycisk zaloguj który jest rokiem który za każdym razem się powtarza nie ma sensu żebyśmy pisali a on wziął i login Button

00:30:50: eperfumy.pl za każdym razem tylko mamy po prostu jedno metodę w której Te kroki możemy Rose.

00:30:57: I Fajne jest to że jeżeli widzimy że w ramach robotów powtarzają nam się pewne czynności Czy mamy kilka robotów które robią to samo to ja co polecam to zrobić sobie interfejs

00:31:08: który będzie zawierał te metody w Kotlinie jest coś takiego że interfejsy mogą mieć domyślne Default implementation i wtedy to bardzo łatwo można sobie właśnie połączyć z tym

00:31:19: bierzemy taki

00:31:20: z który się powtarza w kilku robotach wyciągamy go do interfejsu i potem sprawiamy że wszystkie te roboty implementującej interfejs i wtedy dostajemy tak naprawdę.

00:31:32: Konkretną ten konkretny krok we wszystkich tekstach.

00:31:38: I teraz już na etapie testów integracyjnych korzystałem z nagrywania zrzutów ekranu.

00:31:43: Ale dopiero z podejściem to z mopowaniem wiem i szóstej to Pozwolił nam wykorzystać te screenshoty dużo bardziej.

00:31:54: I mam coś takiego jakby dotykasz od w ogóle polecam polecam się jej przyjrzeć to jest biblioteka która tak naprawdę jest

00:32:02: opakowaniem takim raperem dla biblioteki screenshot test Poland

00:32:06: która robi całą tą ciężką robotę czyli zrzucanie się raki widoków do pliku aż od tak naprawdę

00:32:12: daję przyjemniejszy interfejs do dopisania do używania tego w testach plus lepsze fajniejsze raporty generuje iż ta biblioteka fejsbukowa więc te dwie biblioteki polecam polecam się.

00:32:26: Cały mechanizm tych screenshot

00:32:29: i testów z użyciem z kim shotów działa mniej więcej w ten sposób że screenshoty stają się tak jakby kolejnym poziomem asere

00:32:37: czyli oprócz tam asercji pod tytułem Sprawdź czy przycisk się pojawił na tym ekranie Możemy też zrobić asercje pod tytułem zrób screenshot tego ekranu i za każdym razem kiedy teraz Ktokolwiek będzie testy będzie też robi screenshota i porównywał

00:32:53: screenshoty ze sobą działa to w ten sposób że programista tworząc jakiś test nagrywa po raz pierwszy taki screenshoty wrzuca je do gita.

00:33:03: W odpowiednim katalogu i później biblioteka Puszczając po raz kolejny tak jakby ten ten cały suit testów robi screenshoty i porównuje binarnie

00:33:12: czy te testy testy już odpowiadają tym docelowym Czyli jesteśmy w stanie stwierdzić że jakikolwiek zmiana o jeden piksel spowoduje że test się wywali i to powoduje że trzeba

00:33:26: pracy włożyć w to żeby te testy były w stu procentach stabilne ale to da się uzyskać i jeszcze o tym opowiem jak to zrobić Natomiast teraz Odpowiedz mi sobie na pytanie dlaczego robimy tak jest.

00:33:39: No te testy z shotami Po pierwsze możemy zauważyć przypadkowe zmiany wbiła.

00:33:46: I to są rzeczy które się faktycznie zdarzają i to kilka razy nam uratowało tyłek sytuacjach gdy ktoś zmieniał jakiś styl ponieważ chciał przykładowo

00:33:55: na danym ekranie poprawić wygląd jakiegoś tekstu okazuje się że ktoś przypadkiem użył tego stylu też w jakimś innym miejscu nie wiedzieliśmy o tym

00:34:04: i wtedy jeżeli mamy odpowiednio duże pokrycie tych testów jesteśmy w stanie bardzo szybko wyłapać to już programista tak naprawdę Puszczając Puszczając sobie testy przed przed komitetem przed wystawieniem

00:34:17: nie stanie na Mieszka okej tutaj też się coś zmieniło a nie

00:34:20: to jest jedno po drugie Każdy test jako że ma screenshoty każdy komin tylko że ma screenshoty w sobie ma też Obrazki które można bardzo łatwo po

00:34:31: drzwi na przykład b-baka świetnie pokazuje obok siebie dwa screenshoty można zrobić opcję Pixel gif i wtedy zobaczyć miejsca w których zmieniły się zmieniły się na obrazku te z kimś.

00:34:45: Bardzo dobre to do wychwytywania takich drobnych zmianach na przykład ktoś Doda kropkę w tekście bo miał jakieś zmiany w tekście

00:34:53: i nagle się zmienił tekst test i nie wiadomo tak naprawdę Czemu się zmieniło a tutaj dodana została kropka Natomiast często to jest tak że faktycznie jak ktoś dodaje nowy screenshot też jest druga taka dodatkowa wartość bo dodaje nowy nowy film

00:35:07: to od razu Pull request jest tak jakby ten ten Wpisz odpowiedź właśnie tak jakby dokumentacją tego co zostało w tym czasie zrobię o tym wspomnieć właśnie.

00:35:18: Jeżeli mamy jeszcze coś takiego że mamy jakiś inny jeżeli zeplin firmę czy cokolwiek Gdzie mamy templatki to możemy sobie templatki jeżeli zrobimy jeden do jednego z tymi testami ci na przykład te same teksty wstawimy i tak dalej to jesteśmy bardzo łatwo w stanie borówna

00:35:35: Czy efekt docelowy odpowiada temu co mamy w tym

00:35:39: to też się przy perkach może przydawać i ciągle mamy w każdym momencie mamy tak jakby

00:35:47: komplet wszystkich screenshot z aplikacji która wykonaliśmy więc możemy w dowolnym momencie zobaczyć jak wygląda konkretny ekran w danym stanie to też się czasem przydaje Jak trzeba coś na szybko spraw.

00:36:00: I teraz kilka problemów które napotkaliśmy po to żeby mieć stabilne testy Przede wszystkim musimy mieć stabilną datę i czas Czyli jeżeli gdziekolwiek używacie newday.

00:36:11: To będzie od razu problem z test

00:36:13: co trzeba ustabilizować robi się zwykle jakiś provider interfejs który udostępnia datę czas i wtedy możemy sobie łatwo w teście go zamontować o to żeby zwracał zawsze tą samą datę i ten sam

00:36:24: tak samo W przypadku jeżeli macie gdzieś jakąś randomizacja je przy użyciu kiedyś tam securerandom czy Random to też wtedy trzeba ustawili

00:36:33: trzeba wyłączyć animacje na to jest kilka rozwiązań są są biblioteki A są różnego rodzaju skrypty które wyłączają animacje po to żeby

00:36:45: nie było jakieś tam przejść w trakcie renderowania i stanów nieustalonych powiedzmy Należy wyłączyć kurs

00:36:52: my mamy do tego taką specjalną akcję ale w tej chwili Widzę że niedawno

00:36:59: Shot dodał właśnie funkcjonalność wyłączania testów przed zrobieniem screenshota Czyli jeżeli na ekranie znajduje się kursor tą zostanie ukryty po to żeby nie było sytuacji gdzie migający kursor na różnych renderach tak jakby w różnym stanie się znajduje.

00:37:16: Tak samo z chlorem jeżeli robimy akcje przesunięcia bo na przykład chcemy zobaczyć do ekranu to mogłaby być sytuacja w której ten dół ekranu renderuje się w takim.

00:37:29: Pokazującym scrollbar to też trzeba ukryć po to żeby w różnych stanach nie wyglądało

00:37:34: w różny sposób ukrywanie klawiatury warto o tym pamiętać że przed screenshot zrobić ukrywanie klawiatury bo na różnych emulatorach może w różny sposób wyglądać albo może się w różny sposób wyślę.

00:37:47: Warto żeby wszystkie emulatory których używamy miały ten sam lokal czyli ten sam język ten sam kraju ustaw.

00:37:55: I też warto żeby ustalić konkretne mulator czyli konkretne urządzenie z konkretną wersją systemu z konkretną wers.

00:38:03: Biblioteki i tak dalej ponieważ mieliśmy sytuacja przykład widzieliśmy emulatory te same ale

00:38:11: X86 a x na 2:00 X86 64 czy architektura 64 bitowa i na przykład JPG potrafią się renderować w różny sposób w zależności od architekt

00:38:23: to jest wynika z błędów zaokrągleń który tam się gdzieś pojawiają

00:38:26: felgi są bezstratne w związku z tym Peggy zawsze się w ten sam sposób wędrują ale JPG potrafią się w różny sposób.

00:38:35: I teraz taką konsekwencją tego.

00:38:38: Że mamy nowe podejście spowodowało że trochę inaczej teraz wygląda nasz Development bo jeżeli tworzymy nowy ekran to po pierwsze mamy ten blat które nam zwykle tworzy całą tą przez cały ten czyli View model fragment test do niego od razu robota do niego i tak

00:38:57: to możemy bardzo szybko sobie wyklikać potem jak mamy już ten ten template jesteśmy w stanie w ciągu dosłownie

00:39:04: 30 sekund odpalić pierwszy test Ale to pierwszy to jest zwykle wyświetla Po prostu pusty ekran i wtedy możemy zacząć Korzystając z właśnie z tego że mamy możliwość mocowania całe widoku to możemy przygotować dane które chcemy wyświetlić

00:39:20: i zająć się robieniem samych layoutu jak mamy już same layout.

00:39:25: My to całą resztę czyli całą tą logikę biznesową postaci w modelu use-case i tak dalej i tak dalej Możemy sobie już robić normalne tvd Korzystając z testów jednostkowych.

00:39:37: I

00:39:39: I potem oczywiście zostaje ten krok gdzie faktycznie musimy to odpalić normalnie na urządzeniu sprawdzić czy się połączymy zapi bo oczywiście tutaj się pojawiają jakieś niedokładne to że przykład dokument że będzie się zachowywał w ten sposób okazuje się że zwraca nam jakieś nowe albo coś w tym stylu

00:39:55: musimy uwzględnić przetestować.

00:40:00: Problemy które jeszcze nam zostały i którymi w tej chwili walczymy to jest na przykład emoji okazało się że biblioteka do emoji w zależności od tego na tak naprawdę jeszcze do końca nie wiemy mamy kilka podejrzanych naród.

00:40:14: Emulatorach u różnych osób renderuje w różny sposób

00:40:20: czyli coś podobnego jak z jpk mi tylko że na przykład ustabilizowanie architektury procesora nic tam nie dało i nadal mamy różne różne rendery na różnych urządzeniach z tym się jeszcze

00:40:33: Musimy zmierzyć Czasami mam kodowane A ty po torze

00:40:38: różnego rodzaju jakieś nietypowe przejścia albo animacje na przykład lot i ustabilizować to też jest rzecz która trochę nam wydłuża testy No i pluginy dżinsowych

00:40:50: okazuje się że dosyć trudno jest uzyskać żeby.

00:40:54: Dzień po dniu każdy odpalenie tego o tych testów było w stu procentach stabilne tutaj są jakieś problemy.

00:41:03: Jako alternatywę polecam github Actions Tam faktycznie można dużo

00:41:08: bardziej zarządzać tymi kontenerami które odpowiadają za

00:41:14: i teraz na podsumowanie Co dało nam to podejście to podejście przede wszystkim dało nam prawie w tej chwili już 100% pokrycie x

00:41:24: Czyli mamy mamy jakiś tam im Vision Czy czy 3 zebrina i tak naprawdę mamy wszystko.

00:41:33: Ekrany które udostępnił nam dział designu i jesteśmy w stanie w stu procentach mieć preferencje każdy ten z tych ekranów jest u nas zaimplementowany jako test i wygenerowany w związku z tym jakiekolwiek zmiany na przykład w tym klatkach jesteśmy w stanie w łapy

00:41:51: każdy to nawet mówię że jakiś może spokojnie podejść Junior i w ciągu jednego dnia jestem w stanie pokazać jak stworzyć test łojowy tak żeby bez problemu był w stanie tych testów i pisać ile tylko chcemy.

00:42:07: Dzięki temu że udało nam się zrobić tak dużo pokrycie i wiemy że że mamy tak jakby zabetonowane testy i łojowe i tam Nic się nie może stać bez naszej wiedzy to dużo bardziej zaczynamy się teraz skupiać na te

00:42:20: No gdzie możemy faktycznie zająć się logiką tej aplikacji.

00:42:24: I To spowodowało też że mamy odczuwalnie mniej błędów zgłaszane przez tych testerów manualnych takich błędów właśnie często to było jakieś błędy Jula rowerze tutaj się

00:42:36: jest jakiś tekst źle wyświetlony albo wycentrowany albo coś w tym stylu

00:42:40: to się już dużą listę zdarza ponieważ na przykład na poziomie perki ktoś jest w stanie spojrzeć czy templatka zgadza się z tym co wyrenderować liśmy i łatwo wychwycić na że tutaj się jakieś padding i nie zgadzają albo coś tam

00:42:52: i też tak jak wspomniałem możemy wyłapywać nie konsekwencje w tabletkach okej no.

00:43:01: Tyle jeśli chodzi o mniej polecam spojrzeć na szkołę Androida To jest mój blok w tej chwili który prowadzę tam jest na przykład kabuk narzędzia

00:43:13: które każdy może sobie pobrać i tam jest między innymi właśnie Shot i kilka innych jeszcze fajnych narzędzi do testowania czy do bezpieczeństwa.

00:43:22: I w razie czego ale to są do mnie dane kontaktowe można się ze mną skontaktować Jeżeli ktoś ma jakieś pytania.

00:43:29: Wydaje mi się że w niedługiej przyszłości będę publikował kod źródłowy zawierający właź

00:43:37: przykład takich testów i łojowych gdzie będzie wykorzystanie robota wykorzystanie shota to wszystko będzie na github Actions po to żeby łatwo można było użyć tego jako wzorcu we własnym

00:43:49: tyle ode mnie oddaję głos Dofus.