Close
Dev Radio PL: MUTANT w służbie programisty

Dev Radio PL: MUTANT w służbie programisty

Kilka dni temu wziąłem udział w spotkaniu na Clubhouse w temacie testów. Poniżej kilka moich luźnych notatek w temacie.

Jedna uwaga – programistą byłem sto lat temu, więc poniżej notatki nieprogramistyczne 🙂

Druga uwaga – poniżej są wypowiedzi uczestników debaty, niekoniecznie są to prawdy objawione a opinie wyrażane w jakimś kontekście a linki są dodane ode mnie.

Zorganizowane przez:

Ale brali udział także:


Punktem wyjścia jest przypadek aplikacji legacy, która powstała szybko jako MVP, poszła na produkcję i taki potworek jest utrzymywany. Jak to otestować, bo strach się dotknąć ale trzeba działać.

Często jest tak, że startując development od zera, FE powstaje jako drugi a BE jako pierwszy – daje to 2 problemy:

  • Jak to integrować? Mocki?
  • Kto za co odpowiada? W sensie – mamy błąd i czyja to wina, FE czy BE

Wątek 1

Częsta odpowiedź typowo „grubo” konsultancka to testy kontraktowe.

Testy kontraktowe to może jednak być overkill. 

Wątek 2

W pewnych przypadkach możemy ominąć testy kontraktowe, i spróbować przerzucić je na Selenium. Tam robić testy e2e, bo właściwie kontrakt jest trzymany przez czynnik „białkowy”, tj. ludzi więc powinno być ok. W końcu mamy Swaggery po obu stronach i wiemy jak to działa.

Swagger pomaga bo można półautomatycznie wygenerować wiele testów do API.

Pomysł ten jest jednak wadliwy bo uczestnicy debaty nie lubią selenium: „ja nie promuję selenium, wręcz przeciwnie” 🙂

Tu jest inny duży problem – brak wiary generalnie w sytuacje w których polega się tylko na człowieku a nie na jakimś procesie – człowiek zapomina, myli się, jest ułomny itp…

Wątek 3

Jeśli więc kontrakty to za dużo, to można iść w Mocki i Dummy Mocki.

Ale wtedy i to może się rozjechać, bo kontrakt frontowy jest trzymany we front a backendowy w back. Natomiast plusem jest to że możemy się przetestować niezależnie

Zamiast API możemy też wystawić bibliotekę kliencką – np w JS – i to frontend ją utrzymuje – daje nam to większą pewność, że BE nie zrobi złego Mocka i odwrotnie.

 

Oddzielny wątek: Hotwire – jako wzorzec działania że html jest generowany z backendu – myślimy wtedy jako o 1 aplikacji

Wątek 4

Odwracamy piramidę testów i testujemy e2e. Potem w środku refactor + testy jednostkowe.

Wątek 5

MVP wyrzucić i napisać od nowa 🙂

Oddzielny wątek: legacy – jak stratega przepisania?


Wątek poboczny: narzędzia

Nowe gotowe narzędzia – moc mockowania i kontroli nad warstwą sieciową aplikacji


Wątek poboczny: test coverage

  • Coverage – łatwo zmierzyć unit testy ale trudno zmierzyć pokrycie e2e
  • Dążenie do wysokiego coverage to antipattern
  • Doświadczeni, siwi i łysi programiści mówią że „wolą testować ważne rzeczy tylko”
    • ale powstaje problem jakie to rzeczy?
  • Dobra zasada – pisanie takiego kody który jest “łatwo testowalny” i dopiero, jak już jest potrzeba zmiany tej części aplikacji, to dopisuje się tam test
    • no ale do tego musi być odpowiednia (i odpowiedzialna) architektura
  • Gra w coverage – np. KPI 80% pokrycia, to gra się zaczyna 🙂
    • może być duże pokrycie, ale nic nie testować – np. zero testów logiki a tylko testowanie atrybutów (setery getery)
    • You get what you measure – jeśli tylko pokrycie, to niekoniecznie ono będzie miało sens
  • Dodatkowo – Unit Test – często ludzie źle to rozumieją, a przynajmniej “inaczej” to rozumieją
    • JEst to “Unit of behaviour” CZY “Unit of kawałek kodu”?
      • Behaviour – łatwiej utrzymać a kawałek kodu trudno utrzymywać
      • „Classes are not units” – blogpost na blogu Arkency
    • Wiele obiektów nie ma sensu testować w izolacji – są za małe
  • Line coverage  jako metryka to bardzo mizerna metryka
  • „Jaka jest rola testów w ogóle poza coverage?” 🙂

https://blog.szkolatestow.online/jak-mierzyc-jakosc-testow-line-coverage-branch-coverage-i-testy-mutacyjne/

https://blog.arkency.com/2014/09/unit-tests-vs-class-tests/

https://bulldogjob.pl/news/1195-co-daje-code-coverage


Wątek poboczny: DDD

Domain driven design, read modele dobrze się testuje w izolacji, natomiast na poziomie biznesowych kawałków to jest inny wątek – np. jak testować agregat i czy testować w izolacji? Często testy agregatów są zbyt zabetonowane i nie testują zachowania a tylko „kod”, co implikuje problemy z ich utrzymaniem

 https://geek.justjoin.it/product-design-to-ciagly-rozwoj-jak-pracowac-dla-najwiekszych-marek-i-miec-realny-wplyw-na-ich-produkty


Wątek poboczny: Mutanty

  • Czujesz smell w testach – użyj mutanta 🙂
  • „Mutant mnie uspokaja – bo jak ktoś wrzuca bez testów ale działa to nie wiadomo czy działa”
    • Testy mutacyjne dają możliwość postawienia hipotezy: nie mam żadnych założeń wokół tego co zmieniam a zakładam tylko to, co najgorsze i dlatego odpalam testy mutacyjne – pokazują szybko których testów wokoło brakuje
    • Moją rolą jest doprowadzenie do 100% i zostawić po sobie 100%
    • Raport o testach mutacyjnych jako świetna praktyka
  • „ALE testy mutacyjne pokazują w kontekście jednostki – mutant nie pokaże mi większej logiki biznesowej” a to za mało. Potrzeba „mutantu logiki biznesowej”
    • tego nie ma, ale jak zmieniasz np 3 klasy to zapuszczasz mutanta i sprawdzasz czy metody są otestowane w tych 3 klasach
    • doprowadzasz do 100%
    • i dopiero wtedy zaczynasz zmieniać
  • Żeby użyć mutanta trzeba miec jakies testy już – on testuje testy istniejące (co najwyżej podpowie jakich brak)
  • “Testy mutacyjne są dla nas kubłem zimnej wody, że nasze testy nie są takie wspaniałe”

A jakie zalecenie dla projektu gdzie są testy ale jest założenie że są OK. Inwestować wtedy w mutanty?

  1. Co to znaczy „są ok”?
  2. Kwestia tego jak bardzo się boję, że coś zepsuję

Czego oczekujemy od testów? Jedna z opinii – „nic więcej niż tylko tego, aby nas uchroniły przed regresją, nie uważam że testy są dokumentacją, nie mam już nadziei na to, choć idealistycznie wierzę w tę możliwość”

Sprzedawanie mutanta

  • oszczedzamy na code review” bo automatyzuje
    • nie wszyscy tak uważają, bo code review nie można sprowadzać tylko do sprawdzania testów
  • mutant dodatkowo pomaga bo wskazuje miejsca death code bez pokrycia testami
  • plus jest to “test design buddy” 😉

https://www.youtube.com/watch?v=839JqeMO0-M

https://blog.arkency.com/2015/06/how-good-are-your-ruby-tests-testing-your-tests-with-mutant/ 

https://pl.wikipedia.org/wiki/Testowanie_mutacyjne


Wątek poboczny: Code review

  • Pytanie jak traktujemy testy w code review – znieczulica na testy czy nie?
    • „kurcze przetestujmy to inaczej” kontra „ok, zwiększa nam to coverage” (ale nic nie testuje)
    • “hej ale ten test jest niefajny” – czy to nie jest zbyt wysokie wymaganie dla code review?
  • Powinno być zwracanie uwagi na testy w code review koniecznie!
  • Dużo zależy od DNA programisty i DNA środowiska – albo to robimy (gorzej lub lepiej) albo UDAJEMY, że robimy

Wątek poboczny: Świat testerów i świat programistów

Opinia 1

  • Światy „testerów” i „programistów” się mieszają – tak jak z przeciwnej strony mieszają się światy „biznesu” i „IT”
  • „Nie róbmy więc płotów,  przez które przerzucamy problemy”

Opinia 2

  • grupa testowania oprogramowania na FB to jakieś 32000 osób – więc jest to trochę swiat odrębny, z boku programowania
  • świat idylla kontra rzeczywistość przegrywa – są firmy w których istnieją odmęty czeluści pomiędzy testerami i programistami 🙂

Wątek poboczny: BDD

  • “W żadnym projekcie BDD w pełni mi się nie udało wprowadzić”
  • Idealny świat byłby taki że biznes może to w narzędziu jakimś commitować
  • trzeba wytłumaczyć biznesowi jakie PLUSY będą mieli, że będą nam dostarczać wymagania  właśnie w taki sposób
  • „Given when then” czy „as a …” – samo to nie wystarczy! Bo to nie znaczy automatycznie, że to jest wartość dla projektu = nie znaczy, że ktoś to dobrze zdefiniował!
  • BDD to platforma do komunikacji, a nie do AUTOMATYZACJI – czyli do dogadania się na poziomie językowym/rozmowy
    • Bo domena która jedynie spada to do nas z biznesu bez rozmowy, może być źle zdefiniowana przez nich
    • Trzeba spotkania z biznesem żeby dać im, i nam programistom, możliwość zrozumienia procesu
    • Bo wiadomo – i małpa przeklika taki test, a nie o to chodzi (a chodzi o zrozumienie)
  • Dopóki biznes nie rozmawia z deweloperami to będzie źle – trzeba to wspólnie wypracować
  • BDD to narzędzie do komunikacji a nie tylko jakiś tool np. Cucumber czy inne
  • Nie komunikujmy się przez Jire czy same storiski
  • BDD dobrze napisane książkowo to złoto dla deweloperów – pięknie pokazują wtedy działanie domeny!

https://cucumber.io/tools/cucumberstudio

https://en.wikipedia.org/wiki/Behavior-driven_development


Wątek poboczny: Impact Mapping

Książka Impact Mapping Gojko Adzic

  • Trudno jest byc Product Ownerem
  • Podoba mi się myślenie o asercji biznesowej odłożonej w czasie
    • coś jest ważne dla biznesu, ale pytanie czemu?
    • “bo wydaje nam się że zrobimy 1 milion $ za 5 lat”
    • To ok załóżmy tę asercję
    • Nakłada to wtedy odpowiedzialność na biznes
    • Dobre narzędzie na biznes który mówi niespójnie
    • Bo często jest tak że zajmie to 5 lat ale biznes zarobi 1 dolara
  • IT czelendżuje biznes, bo dlaczego zawsze ma być odwrotnie?
  • Zadawać pytanie: jaki jest zwrot z inwestycji w TEN deadline?

https://www.amazon.com/gp/product/0955683645


Opinia: taki flow, że przy nowym ficzerze:

  • mamy 1 dzień na MVP
    • eksperyment + opis w Gerkinie 
    • daje to gotowe US tego ficzera
  • rozchodzimy się i implementujemy test z Gerkina tak, żeby niósł wartość
  • w międzyczasie powstają testy kontraktowe, mutacyjne itd…
  • finalnie to wszystko ląduje u manual testera
  • jak ficzer się wygrzeje to DOPIERO wtedy robione są testy e2e
  • Uwaga na duplikacje w takich sytuacjach, do tego trzeba podchodzić z zimną głową

  https://www.functionize.com/blog/what-is-gherkin-how-do-you-write-gherkin-tests/


Wątek poboczny: Property based testing 

  • Zadajesz zakres danych wejściowych i przypisujesz założony wynik – framework sprawdza wiele permutacji warunków wejściowych, zwłaszcza brzegowe i testuje wobec nich
  • Framework pomaga znaleźć takie sposoby testów, o których bym nie pomyślał

Inne skrawki zdań 🙂

  • „Nie ma jednego dobrego uniwersalnego sposobu na testowanie frontendu”
  • Frontendowcy pokrzywdzeni bo mówią że „nie muszą pisać testów” bo backend jest przetestowany.
  • Stary programista powie – kiedyś nie było podziału na FE i BE, wszystko było razem i było dobrze 🙂 
  • Firmom się „nie opłaca” mieć manualnych testerów – liczą, że dev to zrobi prawidłowo i jak trzeba to przetestuje
  • “OK, Andrzej poszedł, co teraz…” 🙂

 

W tym momencie minęła 1 godzina i 40 min i musiałem się rozłączyć ale wiem, że dyskusje trwały dłużej.

Jeśli któryś z uczestników chce coś dodać – zapraszam, wyedytuję wpis 🙂

Greg

Podziel się

Leave a Reply

Your email address will not be published. Required fields are marked *