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.
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ł
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
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
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
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!)
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
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
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
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?
ż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 – … ?
Rafał Łasocha
swistak35
chriscoyier
kastner
smashingmag
destraynor
paulrobertlloyd
andyhume
brettharned
swwweet
malarkey
michaelherold
lauravandoore
