Testy których nie napiszę - DRUG #95

Transcript

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

2. Będzie o wszystkim, głównie o testowaniu, w formie mojego marudzenia

   i mam nadzieję dyskusji :)

3. Nie napiszę testu...

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ą”

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.

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

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

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ł

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

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

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

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

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!)

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

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

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

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?

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 – … ?

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

20. ...bo to trudne • vide ostatni talk Roberta :) –

    testowanie ORDER BY, preloadów, etc.
21. None