Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Testy których nie napiszę - DRUG #95

Rafał Łasocha
May 20, 2019
170

Testy których nie napiszę - DRUG #95

Rafał Łasocha

May 20, 2019
Tweet

Transcript

  1. Testy których nie napiszę
    Rafał Łasocha, Arkency
    DRUG #95, 20.05.2019

    View full-size slide

  2. Będzie o wszystkim, głównie o testowaniu,
    w formie mojego marudzenia i mam nadzieję
    dyskusji :)

    View full-size slide

  3. Nie napiszę testu...

    View full-size slide

  4. …na to, że nie wydarzy się to czego
    się nie spodziewam

    klasyczny problem

    nie napiszemy asercji na wszystkie skutki uboczne, że się “nie wydarzą”

    View full-size slide


  5. Moglibyśmy używać mocków, przy założeniu że korzystamy z DI wszędzie, to daje w miarę
    sensowną gwarancję
    – Czy “dyscyplina DI” jest do przeprowadzenia w zespole? Pewnie tak
    – Ale mocki mają inne wady, przez które za nimi nie przepadamy i raczej nie chcielibyśmy
    mieć kodu pokrytego “w 100%” mockami
    – Nawet to nie pomoże na pośredni coupling – np. spodziewamy się, że zostanie
    opublikowany fakt, ale nie spodziewaliśmy się, że opublikowanie tego faktu wywoła
    wysłanie jakiegoś e-maila.

    View full-size slide


  6. Moglibyśmy założyć, że wszyscy programiści w zespole są zdyscyplinowani i odpowiedzialni,
    więc przed każdym commitem dokładnie przejrzą swoje zmiany, a code review wyłapie
    niedoskonałości

    View full-size slide


  7. Moglibyśmy założyć, że wszyscy programiści w zespole są zdyscyplinowani i odpowiedzialni,
    więc przed każdym commitem dokładnie przejrzą swoje zmiany, a code review wyłapie
    niedoskonałości

    View full-size slide

  8. …na wymagania, których nie znamy

    Przypadek, który się na pewno każdemu kiedyś przydarzył
    – W programie mamy wiele funkcjonalności
    – Kilka różnych funkcjonalności użytych ze sobą, spięło się w kombinację, która zachowuje
    się dziwnie
    – Biznes nie pomyślał o takim użyciu tych funkcjonalności
    – Myśmy nie pomyśleli implementując
    – Klient pomyślał

    View full-size slide


  9. Co znaczy dziwnie?
    – Niekoniecznie “błędne” (filozofia wjeżdża)
    – Po prostu jak już wiemy, że ta kombinacja może wystąpić, to wyspecyfikowalibyśmy jej
    działanie inaczej, np. przyjmując jako kryterium intuicyjność dla użytkownika

    View full-size slide


  10. Zignoruj problem, bo rzadko ktoś tego używa
    – Biznes może się na to zgodzić
    – Co z użytkownikiem? (zostawić obsłudze klienta? Wyświetlać błąd?)
    – Co z programistą?

    Jeżeli to rzadki / mało dochodowy przypadek, to biznes pewnie nie będzie miał
    problemu, żeśmy nie pomyśleli

    W końcu on sam też nie pomyślał

    ...ale problem pozostaje, to nasza rola wiedzieć jak nasze programy się zachowują i
    zadawać biznesowi pytania, kiedy jest “dziura w dowodzie”, a nie na odwrót

    View full-size slide


  11. Bounded contexty, głupcze
    – Może gdyby te 3 funkcjonalności były lepiej wyodrębione, to łatwiej byłoby zauważyć
    możliwy scenariusz? (przemawia za tym fakt, że w lepiej wyodrębionych BC jest z reguły
    mniej punktów interakcji)
    – A może wcale nie, jeszcze łatwiej byłoby go pominąć? (przemawia za tym fakt, że lepiej
    wyodrębnione BC lepiej abstrahują od pozostałych)
    – => tak czy siak, potencjalne rozwiązanie sprowadza się do lepszej analizy subdomen i
    umiejętności ich implementacji jako BC

    View full-size slide

  12. ...na wymagania, które są trudne

    Najlepszy przykład – Uncle Bob próbował napisać Dijkstrę
    – Dobry programista, świetny w TDD, pisze bardzo prosty algorytm

    View full-size slide


  13. “I was at SCNA the other day, and someone approached me about TDD and Dijkstra’s
    algorithm. He wondered if you could find a sequence of tests that would lead you to the
    algorithm. This sounded like a fun little exercise, so I decided to give it a try here.”

    “This, for all intents and purposes is Dijkstra’s algorithm. (…) But the goal was to see whether it
    was possible to use TDD to stepwise approach Dijkstra’s algorithm. I think it is; though I have to
    say the approach was pretty jerky. (…) Still, each new test exposed weaknesses in previous
    implementation that could be corrected in a relatively straightforward manner.”

    Rzeczywiście udało mu się napisać poprawny algorytm dijkstry

    Pogrubiony fragment – idealna sytuacja, każdy krok był albo refactoringiem, albo dopisaniem
    nowej specyfikacji i sprawieniem, że testy przechodzą (czyli TDD!)

    View full-size slide

  14. Problem

    Nie wszystkie przejścia były poprawne
    – Specyfikacja (zero krawędzi)
    – 3x Refactoring (bo brzydki kodzik; klasyczne refactoringi)
    – Specyfikacja (przypadki brzegowe, typu brak ścieżki, brak wymaganego początku / końca)
    – Specyfikacje/refactoringi (jedna krawędź, dwie krawędzie, trzy krawędzie) – po tym
    miejscu, podobno algorytm miał być poprawny, ale nie był
    – Performance “refactoring” (bez dodawania nowego testu) – jeszcze gorzej, dwa bugi
    zamiast jednego
    – Performance “refactoring” (bez dodawania nowego testu) – naprawienie obu poprzednich
    bugów oraz rzeczywiście osiągnięcie poprawnego algorytmu

    View full-size slide


  15. Nie chodzi o to, że się nie udało zrobić poprawnej implementacji tylko za pomocą TDD

    Chodzi o to, że wymagania były na tyle łatwe trudne, że doświadczony programista popełnił
    błędy i ich nie zauważył

    Podświadomie pewnie wiedział, jak algorytm ma “docelowo” wyglądać, więc zrobił dwa
    “performance refactoring”, które wcale nie były performance refactoringami. Pierwszy, mógłby
    być, gdyby kod był poprawny, a drugi w ogóle nie był – to była kluczowa część poprawnego
    działania algorytmu

    View full-size slide

  16. ...bo to trudne

    wielowątkowość / race conditions – wiele różnych scenariuszy, ciężko upewnić się że wszystkie
    możliwe otestowane
    – Można wykorzystać permutacje
    https://blog.arkency.com/2016/06/cover-all-test-cases-with-permutation/
    – Można wykorzystać niskopoziomową implementację (np. SQL)
    https://blog.arkency.com/2015/09/testing-race-conditions/
    – Property based testing (John Hughes for Dropbox)
    https://www.youtube.com/watch?v=H18vxq-VsCk

    View full-size slide

  17. ...bo to trudne

    UI – bo przez naturę UI, przemieszane są elementy domeny z logiką prezentacji, ale jednak
    logika domenowa jest z reguły znacznie zredukowana
    – snapshot testing
    – full integration UI tests (capybara)
    – shadow rendering testing
    – screenshot testing?

    View full-size slide

  18. ...bo to trudne

    Zmiana kodu – jak się upewnić, że mój nowy kod zagra dobrze z danymi, które aktualnie są na
    produkcji? Jeżeli mam rolling deployment, jak upewnić się że działający jednocześnie stary i
    nowy kod nie będą ze sobą zgrzytać?
    – https://blog.arkency.com/2015/10/rolling-back-complex-apps/
    – Testy migracji danych
    – Testy dla konkretnych błędów które wystąpiły w przeszłości
    – … ?

    View full-size slide

  19. ...bo to trudne

    Testowanie miejsc, gdzie korzystamy z 3rd parties

    Testowanie miejsc, gdzie 3rd parties korzystają z naszego API (kompatybilność wsteczna,
    wersjonowanie)

    Testowanie integracji backend/frontend

    Testowanie wydajności

    …i pewnie wiele innych

    View full-size slide

  20. ...bo to trudne

    vide ostatni talk Roberta :) – testowanie ORDER BY, preloadów, etc.

    View full-size slide