Android ❤️ Unit Testy
Android ❤️ Unit Testy

Android ❤️ Unit Testy

Tags
Hidden
Hidden
Published
October 3, 2023
Author

Android ❤️ Unit Testy, czyli praktyczny kurs testów dla Android developerów

Pytanie nie brzmi, czy powinno się testować kodzik.

Prawdziwe pytanie to – czy możesz sobie pozwolić na brak testów?

Gdy już ogarniesz testy, to będziesz mieć…
  • lepszą pozycję na rynku pracy (zobacz w ilu ogłoszeniach wspominają o jUnit lub Mockito)
  • zrozumienie biznesu stojącego za aplikacją
  • mniej wyrwanych włosów z głowy podczas debugowania
  • lepszą produktywność: nie zrobisz tyle błędów typu “to miało być w ifie, a nie w elsie”
  • szybszy development: zamiast za każdym razem odpalać apkę na emulatorze, odpalasz jedynie test

 
Co pisanie testów da Twojemu projektowi i firmie?
  • wydajniejszą pracę nad nowymi funkcjonalnościami
  • bezpieczniejszy refaktor (nawet w legacy)
  • większą pewność w deploymencie (nawet w piątki!!!!)
  • wzrost kultury jakości w zespole i w firmie
  • lepszą architekturę aplikacji i design kodziku – pisanie testów promuje clean architecture
  • lepszą produktywność: czytelne testy pozwalają efektywniej współpracować nad kodem w zespole
 
👉
Jeśli Twój manager lub szalony product owner upadł na głowę i twierdzi, że „my nie mamy czasu na testy”, to możesz mu przedstawić poniższe fakty…

 

„PM mówi, że nie mamy czasu na testy”

  • zmień project managera albo firmę [Image: 😎]
  • koszt napisania testów pod każdego taska: +10% czasu na development
  • koszt naprawy głupiego błędu, bo nie było wcześniej czasu na testy: +99999% czasu na naprawy
  • unit testy -> szybszy rozwój produktu
  • unit testy -> bezpieczniejsze i szybsze wdrożenia

 
Scenariusz 🚫 A: nie masz testów w projekcie:
  • bierzesz taska z backlogu
  • piszesz implementację (3h)
  • pushujesz do mastera
  • deploy do Play Store (zajmuje 3 dni)
  • część userów ma CRASH bo JSON jest źle parsowany
  • robisz rollback do poprzedniej wersji (kolejne 3 dni)
  • szukasz błędu i naprawiasz buga (1-2 dni)
  • wypuszczasz nową wersję (3 dni)
Całość: ~8 dni roboczych na wdrożenie poprawek
 
Scenariusz ✅ B: piszesz testy, którym możesz zaufać:
  • bierzesz taska z backlogu
  • piszesz implementację (3h)
  • tworzysz testy (1h)
  • znajdujesz błąd w formatowaniu JSONa
  • poprawiasz implementację (20min)
  • pushujesz do mastera
  • deploy do Play Store
  • userzy są szczęśliwi
 
 
Napisanie kodu trwa zajmie Ci troszkę więcej czasu, ale znacząco minimalizujesz ryzyko wystąpienia głupiego błędu na produkcji.
Zgadza się. Task zajmie troszkę więcej czasu.
Za to oszczędzisz sporo nerwów jakby coś miało pójść źle (a zgodnie z prawem Murphy'ego, na pewno pójdzie).
Co się bardziej opłaca? Matematykę zostawiam Tobie.

Są zasadniczo dwie opcje finansowania tego programu:
  1. Wykorzystujesz budżet szkoleniowy w firmy w której pracujesz na ten kurs (profit)
  1. Inwestujesz samodzielnie w ten kurs i dzięki temu zdobywasz lepszą pracę w firmie która budżet szkoleniowy posiada (również profit)

Program

🖥️ Konfiguracja środowiska

  • jUnit5 w build.gradle
  • jUnit4 i jUnit5 – czy można mieć oba?
  • Inne sposoby na odpalanie testów
  • Struktura testu
  • Jak możemy nazwać test?
  • Praca domowa
  • Repozytorium
 

🧪 Test Doubles: Stub & Fake

  • Czym jest unit w unit teście?
  • Nasz System Under Test
  • Mockito: prosty Stub
  • Mockito: mockujemy finalne klasy
  • Mockowanie bez frameworków
  • Ulepszamy stuby z Mockito-Kotlin
  • doReturn vs doAnswer
  • MockK vs Mockito w stubach

🔍 Asercje bez tajemnic

  • Jak działa asercja?
  • Biblioteki z asercjami
  • Jedna asercja failuje cały test
  • A co jeśli chcemy mieć jednak wiele asercji
  • Czytelne asercje – dodawanie message
  • Budujemy własną asercje
  • Materiały dodatkowe

🧪 Test Doubles: Mock i weryfikacje

  • Oto co będziemy testować
  • Mockito: sprawdzenie argumentów wywołania metody
  • Mockito: Matchery
  • Mockito: Never

🔃 Kotlin Coroutines w testach

  • Jak przetestować korutyny?
  • runBlocking vs runBlockingTest
  • Test use case’u z suspend fun
  • Testowanie Flow

🔃 RxJava w testach

  • Single, blockingGet i TestObserver
  • Single + czas
  • Test use case’u z Single

📱Testujemy ViewModele!

  • Co testujemy? Stan początkowy viewmodelu i prosty test.
  • Obserwujemy zmiany w ViewModelu
  • Kontroluj korutyny w ViewModelu
  • Podsumowanie testu
  • Don’t repeat yourself
  • ViewModel + StateFlow

📱Model-View-Presenter

  • DispatchersFacade
  • Weryfikacja View z MockK
  • Weryfikacja View – Error
  • Budujemy robota dla View

📱Model-View-Intent

  • Przykład MVI – LoginScreen
  • Budujemy ViewRobota
  • RxJava i fasada dla Schedulerów
  • Zmiany stanu ViewRobota
  • Podsumowanie dla ViewRobotów

⛈️ Dirty Architecture

  • Wstęp
  • Konfiguracja
  • Pierwszy Use Case
  • Refaktor w Activity…
  • Refactor c.d
  • org.json.JSONObject

🧪 Inne rodzaj definicji testów: specyfikacje

  • Konfiguracja
  • Before, After
  • FreeSpec i zagnieżdżanie
  • BehaviorSpec
  • Ćwiczenie

🖥️ Wprowadzenie do CI: Github Actions

  • Jak wygląda workflow na CI?
  • Dodanie konfiguracji prosto z repozytorium
  • Quickstart
  • Bardziej złożona konfiguracja
  • Marketplace akcji
  • Co budować na PR? A co po pushu do mastera?
  • Zadanie do wykonania

🧪 Testy Parametryczne

  • jUnit5 Argument Source
  • jUnit5 dynamicTests
  • Kotest forAll
  • Type Safety w testach parametrycznych

📝 Testy API

  • Wstęp – testowanie Jsonów
  • Lokalny Json w testach
  • Gson – test mapowania
  • kotlinx.serialization – test mapowania
  • O czym pamiętać?

🖼️ GraphQL

  • Opis API
  • Aplikacja
  • Co będziemy testować
  • Test nazwy oraz emotki
  • Test waluty wraz oraz refactor
  • Test języka
  • Test Builder
  • Porównanie sposobów tworzenia danych
  • Tworzenie danych – dodatek dla DSL
  • Sanity test
  • Odpowiedzi JSON
  • Interceptor pod testy
  • Testy Happy path
  • Testy Sad path
  • Weryfikacja zmiennych
  • MockServer
  • Podsumowanie
  • Zadanie domowe

🎁 Bonusy

  • Testowanie z Log.d i Timber.d
  • DateTime + testy?
  • Test Doubles Cheatsheet
  • 7 grzechów testowania na Androidzie (nagranie webinaru)
  • Idiomatic Kotlin in Tests (Droidcon Berlin 2021)
  • Grupa dyskusyjna
  • Baza pytań rekrutacyjnych

 
 
 

 

Zdobądź wiedzę. Wykorzystaj ją w praktyce.

Zdobądź wiedzę

notion image
Ucz się w swoim tempie z lekcji wideo, przetestuj załączone repozytoria z kodem.
 

Wykorzystaj ją w praktyce

notion image
Skopiuj najlepsze patterny na testowanie do swojego projektu we wzorcach MVVM, MVI, MVP..
 

Jak to działa?

 

1. Zacznij dziś 📅

… albo kiedy Ci będzie wygodnie. Nie musisz rezerwować specjalnego czasu na spotkania całej grupy. Uczysz się w swoim własnym tempie. O 7 rano? Ok. Po 23? Nie ma sprawy.

2. Studiuj jeden moduł w jednym tygodniu 🎓

… i wdrażaj od razu techniki w projekcie w pracy. Albo w side projekcie. Zmiany wprowadzaj powoli. Ewolucja, nie rewolucja.

3. Zdobądź dożywotni dostęp 💎

Frameworki przychodzą i odchodzą, ale to, czego się nauczysz w testów, zawsze będzie aktualne. Możesz wrócić i przejrzeć kurs w dowolnym momencie.
 

Instruktorzy

Jarosław Michalik

Jarek
Jarek
Google Developer Expert w dziedzinie Kotlina. Fanatyk testów. Założyciel Szkoły Kotlina, KotlinTesting, współtwórca społeczności KlubMobile.pl

Aleksander Jaworski

Aleksander
Aleksander
Praktyk Test-Driven-Development. Pasjonat Kotlin Multiplatform. Twórca bloga akjaw.com, autor w Kotlintesting.com. Ekspert w społeczności KlubMobile.pl
Tworzymy ten kurs w odpowiedzi na najczęstsze wyzwania z jakimi mierzą się zawodowi programiści Androida.

 
 
 

Często zadawane pytania

Q: Czy kurs jest drogi? Jak mogę go sfinansować?
A: Rozumiem, że koszt może być dla niektórych osób barierą. Jednak warto pamiętać, że inwestycja w edukację to inwestycja w przyszłość. Możliwe jest wykorzystanie budżetu szkoleniowego z firmy na ten kurs. Jeśli takiej możliwości nie ma, to pamiętaj, że zdobycie tych umiejętności może pomóc Ci znaleźć lepszą pracę, która takie możliwości oferuje. Dodatkowo masz możliwość skorzystania z rat 4*0%

Q: Czy pisanie testów nie wydłuży czasu potrzebnego na rozwój oprogramowania?
A: Na pierwszy rzut oka, pisanie testów jednostkowych może wydawać się jak dodatkowe obciążenie, które wydłuża czas dewelopmentu. Ale to jest perspektywa krótkoterminowa. Pisanie testów jednostkowych pomaga wykryć i naprawić błędy wcześniej, co ostatecznie oszczędza czas i koszty w długim okresie. Zamiast spędzać dni na szukaniu i naprawianiu błędów po wdrożeniu, możemy znaleźć i naprawić te błędy podczas procesu dewelopmentu1.

Q: Czy kurs jest odpowiedni dla mojego poziomu zaawansowania?
A: Kurs "Android ❤️ Unit Testy" jest skierowany do programistów Android, którzy chcą poprawić swoje umiejętności pisania testów jednostkowych. Jeśli jesteś początkującym programistą, kurs może wymagać od Ciebie dodatkowego wysiłku, ale dostarczy Ci solidnej podstawy wiedzy. Jeśli jesteś doświadczonym deweloperem, kurs może pomóc Ci usystematyzować i pogłębić Twoją wiedzę, nawet jeśli niektóre koncepcje mogą Ci już być znane.

Q: Czy powinienem zainteresować się tym kursem, jeśli nie używam technologii Android lub języka Kotlin w mojej codziennej pracy?
A: Kurs skupia się na testach jednostkowych w kontekście Androida i języka Kotlin, więc jeśli nie pracujesz z tymi technologiami, niektóre części kursu mogą nie być dla Ciebie bezpośrednio stosowane. Jednakże zasady pisania testów jednostkowych są uniwersalne i mogą być przeniesione do innych środowisk. Więc nawet jeśli nie używasz Androida lub Kotlina, kurs może być dla Ciebie wartościowy, ale nie tak wartościowy jak dla osób zajmujących się Androidem.

Q: Jak działa 30 dniowa gwarancja satysfakcji?
Jeżeli kurs nie spodoba Ci się (w co wątpie), piszesz do mnie maila, a ja zwracam Ci 100% pieniędzy.

Q: Czy dostanę fakturę?
Tak. W tym celu podczas procesu zakupu należy podać dane firmy, w tym numer identyfikacji podatkowej (NIP).

Q: Czy jest możliwość wykupienia licencji dla całego zespołu?
Tak. W tym celu napisz bezpośrednio na jarek@michalik.tech i wygeneruję specjalny link z grupową zniżką.