Temat: Czy jeden test powinien testować jedną rzecz?

Nie życzę Ci abyś musiał się na własnej skórze przekonać o tym jak "wspaniałym" doświadczeniem jest utrzymywaniem takiego pola minowego jakim jest system Legacy bez testów.

... Jakieś studia podyplomowe na SGH robiłem...

Gratuluję, ale chyba bez związku :)

Były czasy, że pisanie testów jednostkowych nie było jakoś specjalnie na porządku dziennym. Systemy powstawały, działały. Ba działają do dziś.

Oczywiście. Piramidy też zbudowano bez wykorzystania nowoczesnych narzędzi. I ba - stoją do dziś!

Obaj patrzycie na świat z perspektywy posiadania testów. Ich brak

to ZŁO :)

Chyba jednak niczego się nie dowiem, będzie udowadnianie. A tego właśnie chciałem uniknąć...

Myślę, że znacznie przejaskrawiłeś moją wypowiedź. W swoich postach podawałem przykłady, które pokazują, że testy jednostkowe są przydatne - szczególnie w systemach, które "żyją" wiele lat. Próby refactoringu kodu, który nie ma testów są zwyczajnie niebezpieczne bo ryzyko wprowadzenia błędu, który nie zostanie wcześnie wykryty jest duże. Utrzymanie takich systemów jest bardziej kosztowne. Nie muszę nic nikomu udowadniać - zrobili to dużo mądrzejsi ode mnie. Ja chciałem się jedynie podzielić swoim zdaniem.

Ja również pracowałem przy systemach z zerową ilością testów. Aktualnie pracuję z takimi, gdzie staramy się je utrzymywać i pisać nowe. Różnica - nawet dla ludzi nieźle znających system - jest bardzo odczuwalna bo możemy bezpieczniej modyfikować nawet "core'owe" części systemu.

A to, że można bez - oczywiście, że można. Wiele rzeczy można - pytanie - czy na pewno bez testów jest lepiej tylko dlatego, że szybciej ?

Pozdrawiam.Ten post został edytowany przez Autora dnia 13.08.13 o godzinie 20:43

Temat: Czy jeden test powinien testować jedną rzecz?

Michał Z.:

Nie mam ochoty na udowadnianie komukolwiek czegokolwiek. Podyskutować, czegoś się dowiedzieć - bardzo chętnie.

...

Były czasy, że pisanie testów jednostkowych nie było jakoś specjalnie na porządku dziennym. Systemy powstawały, działały. Ba działają do dziś. Czy to ma sens? Ciężko powiedzieć. Obaj patrzycie na świat z perspektywy posiadania testów. Ich brak to ZŁO :)
Chyba jednak niczego się nie dowiem, będzie udowadnianie. A tego właśnie chciałem uniknąć...

hmm, no ale co w mojej (bo rozumiem ze jestem w tej grupie) odpowiedzi było nie na miejscu. Każdy myśli przez pryzmat własnych doświadczeń, moje są takie: nikt nie chce pracować w projektach bez testów automatycznych, brak testów nie jest ZŁEM. Ale niemożność weryfikacji swojej pracy, spędzanie 95 procent czasu na analizie i zgadywaniu jak działa kod (z 80 procentowym prawdopodobieństwem złego zinterpretowania czyjegoś algorytmu a w rezultacie kolejnych zwrotów systemu z produkcji, naciągania budżetu kosztowego / czasowego / frustracji klienta) bo nie ma testów, jest ZŁEM. Poddałeś tezę że po co pisać testy skoro klient i tak wywróci funkcjonalność. Jakiej odpowiedzi / wiedzy spodziewałeś się od innych po takim stwierdzeniu? Ze ktoś przyklaśnie i powie masz rację, wystarczy silna motywacja zespołu do nie robienia błędów itp. Nie staram się Ciebie atakować po prostu ustosunkowałem się do Twojej tezy przez podanie skrajnego przykładu (wcale nie nierealnego). Jeżeli dyskusja nie idzie w kierunku oczekiwanym przez Ciebie to doprecyzuj o czym chciałeś podyskutować?

Temat: Czy jeden test powinien testować jedną rzecz?

Jarosław S.:

Michał Z.:
Nie mam ochoty na udowadnianie komukolwiek czegokolwiek. Podyskutować, czegoś się dowiedzieć - bardzo chętnie.

...

Były czasy, że pisanie testów jednostkowych nie było jakoś specjalnie na porządku dziennym. Systemy powstawały, działały. Ba działają do dziś. Czy to ma sens? Ciężko powiedzieć. Obaj patrzycie na świat z perspektywy posiadania testów. Ich brak to ZŁO :)
Chyba jednak niczego się nie dowiem, będzie udowadnianie. A tego właśnie chciałem uniknąć...

hmm, no ale co w mojej (bo rozumiem ze jestem w tej grupie) odpowiedzi było nie na miejscu. Każdy myśli przez pryzmat własnych doświadczeń, moje są takie: nikt nie chce pracować w projektach bez testów automatycznych,

Mi tam rybka. Za to do szału doprowadza mnie brak sensownego logowania. Monitoring też bardzo sobie cenię.

brak testów nie jest ZŁEM. Ale niemożność weryfikacji swojej pracy, spędzanie 95 procent czasu na analizie i zgadywaniu jak działa kod (z 80 procentowym prawdopodobieństwem złego zinterpretowania czyjegoś algorytmu a w rezultacie kolejnych zwrotów systemu z produkcji, naciągania budżetu kosztowego / czasowego / frustracji klienta) bo nie ma testów, jest ZŁEM.

Po pierwsze założenie, że testy powiedzą co robi kod jest dość mocne. Jest takie coś jak "clean code". Ponoć nawet zakłada się brak dokumentacji w kodzie. Nie jest potrzebna. To podejście wymaga rozdrobnienia metod, klas. Efekt jest taki, że testuje się parszywie. Druga sprawa to w dużej ilości tego wszystkiego sens może umknąć... Jedno z podejść i tyle. Inne zakłada podział na warstwy - wadą jest armia metod dostępowych.
Jak mam grzebać się w kodzie wolę drugą metodę. Co pośrednio nakłada pewien reżim na testy. Z drugiej strony maszynka generująca jdoce, z których kompletnie nic nie wynika? Co to ma wspólnego z testami? A no - jak mam wiedzieć co jest robione to może lepiej to napisać? Jedno i drugie kosztuje. Mając ograniczony budżet na coś się trzeba zdecydować. Oba posty zabrzmiały jak "testować Panowie". No, a z tego nic nie wynika - dla mnie przynajmniej.

Poddałeś tezę że po co pisać testy skoro klient i tak wywróci funkcjonalność. Jakiej odpowiedzi / wiedzy spodziewałeś się od innych po takim stwierdzeniu? Ze ktoś przyklaśnie i powie masz rację, wystarczy silna motywacja zespołu do nie robienia błędów itp. Nie staram się Ciebie atakować po prostu ustosunkowałem się do Twojej tezy przez podanie skrajnego przykładu (wcale nie nierealnego). Jeżeli dyskusja nie idzie w kierunku oczekiwanym przez Ciebie to doprecyzuj o czym chciałeś podyskutować?

Wyjeżdżanie z tekstem, że nie chciałby zobaczyć systemu legacy bez testów... do kogoś, kto takie systemy oglądał jak ja byłem na pierwszym roku... Pewnie się nie znam, ale na Pradze to nie jest komplement.

Co chciałem uzyskać? A no dowiedzieć się jak inni łapią równowagę między wieloma obszarami, na które można wydać kasę w projekcie. Nie chodzi o to, czy testować a jak to robić, żeby było efektywnie. Stawianie sprawy, że testy mają być traktowane jak kod produkcyjny - nie jest efektywne. No, przynajmniej ja to tak widzę. Sporo zależy od projektu, klienta... Co najwyżej - może się okazać, że przy sprzyjających okolicznościach będzie efektywne.

Temat: Czy jeden test powinien testować jedną rzecz?

Nie wiem co ta dyskusja ma udowadniać? Czy da się pisać nowe aplikacje bądź utrzymywać kod legacy bez testów? No pewnie że się da, robiłem i w sumie nadal robię (w sensie utrzymania kilkunastoletnich systemów). Czy to przyjemne i efektywne? Pewnie że nie. I choć wydaje mi się, że znam już ten kod niemal na wylot, zdarzało się, że po niewielkich modyfikacjach wychodził bug który przy okazji popełniłem. I to nie od razu, tylko np. po wielu tygodniach.

Kod z testami jest łatwiejszy do utrzymania i rozwijania, tak się po porostu pracuje efektywniej i na dłuższą metę taniej. Pewnie, nie popadać w paranoję testowania każdej jednej metody, ale zestaw testów na główne procesy biznesowe bardzo się przydaje. I w takim kontekście - nawet lepiej, jak jeden test testuje więcej niż jedną rzecz, a cały proces.

Dlatego w jednym projekcie oprócz testów jednostkowych mam testy integracyjne, oraz - bezcenne! - testy regresji (tutaj akurat na zasadzie porównywania generowanych z aplikacji requestów z zapisanymi w plikach tekstowych wzorcami). Wszystko zautomatyzowane na JUnit. Szczególnie te ostatnie nieraz ratowały mi tyłek przed puszczeniem na produkcję niby drobnej zmiany, która mogła spowodować duże problemy tam gdzie się tego kompletnie nie spodziewałem.

Ograniczony budżet? Testować to co najważniejsze, przynajmniej cały proces biznesowy na zasadzie czarnej skrzynki - jak nagle rezultat przestanie się zgadzać - wtedy testy powiedzą mi, "wiedz, że coś się dzieje", a dalej poszukam ręcznie. To mniej stresujące niż dowiedzieć się tego z maila od klienta i przekopywać się przez (najdokładniejsze nawet) logi.

Temat: Czy jeden test powinien testować jedną rzecz?

Michał Z.:

Po pierwsze założenie, że testy powiedzą co robi kod jest dość mocne. Jest takie coś jak "clean code". Ponoć nawet zakłada się brak dokumentacji w kodzie. Nie jest potrzebna. To podejście wymaga rozdrobnienia metod, klas. Efekt jest taki, że testuje się parszywie. Druga sprawa to w dużej ilości tego wszystkiego sens może umknąć... Jedno z podejść i tyle. Inne zakłada podział na warstwy - wadą jest armia metod dostępowych.

Jak można porównywać reguły Clean Code z architekturą warstwową aplikacji ? Przecież to zupełnie inne rzeczy. Rozdrobnienie klas wynika wprost z Single Responsibility Principle. Kod może się samodokumentować, ale żeby osiągnąć ten poziom pisania kodu to trzeba ćwiczyć wiele lat i dodatkowo poświęcać sporo czasu na refactoring.

Jak mam grzebać się w kodzie wolę drugą metodę. Co pośrednio nakłada pewien reżim na testy. Z drugiej strony maszynka generująca jdoce, z których kompletnie nic nie wynika? Co to ma wspólnego z testami? A no - jak mam wiedzieć co jest robione to może lepiej to napisać? Jedno i drugie kosztuje. Mając ograniczony budżet na coś się trzeba zdecydować. Oba posty zabrzmiały jak "testować Panowie". No, a z tego nic nie wynika - dla mnie przynajmniej.

JavaDoc - nigdy nie pisałem, że jest bardzo użyteczny. Problem z dokumentacją jest taki, że jej utrzymanie kosztuje dużo. Dodatkowo - żaden program nie sprawdzi Ci, czy Twoja metoda robi to, co jest napisane. Test jednostkowy owszem - zakładając oczywiście odpowiednią granulację metod.

Dodatkowo - pomijając TDD - pisanie testów jest jednym z pierwszych miejsc, w których programista testuje swój kod. Bada przypadki brzegowe itp itd. Takie testy mogą właśnie być traktowane jako kod, który dokumentuje kod aplikacji - jak używać, jakie przypadki brzegowe są akceptowane itp itd. Teraz wyobraź sobie opisanie tego wszystkiego w JavaDoc - dla mnie masakra.

Co chciałem uzyskać? A no dowiedzieć się jak inni łapią równowagę między wieloma obszarami, na które można wydać kasę w projekcie. Nie chodzi o to, czy testować a jak to robić, żeby było efektywnie. Stawianie sprawy, że testy mają być traktowane jak kod produkcyjny - nie jest efektywne. No, przynajmniej ja to tak widzę. Sporo zależy od projektu, klienta... Co najwyżej - może się okazać, że przy sprzyjających okolicznościach będzie efektywne.

Efektywność jest bardzo obszernym pojęciem. Twoim zdaniem nie jest efektywne ponieważ kosztuje czas - zarówno ich pisanie jak i utrzymywanie. Oczywiście - kosztuje dużo. Ale dług technologiczny zaciągany dzień po dniu poprzez brak testów (jednostkowych, integracyjnych itp itd) jest moim zdaniem dużo większy. Nie bez znaczenia jest również fakt, że przy dobrze utrzymanym zestawie testów (unit, integracyjne, e2e, performance) czas "time to market" ulega znacznemu obniżeniu, co w dzisiejszych czasach może być dla wielu biznesów kluczowe. Wiele firm odchodzi od testów klikanych w stronę automatycznych - oczywiście nie całkowicie, ale wagi pomiędzy nimi zmieniają się dość dynamicznie.

Oczywiście wiele zależy od projektu i klienta. Od początku zaznaczałem dużą różnicę pomiędzy "produktem" a systemem "na zamówienie" - mam nadzieję, że tego nie przeoczyłeś.

Jeśli miałbym ograniczony budżet na projekt, to skupiłbym się na napisaniu testów do tej części systemu, która będzie modyfikowana najczęściej. To byłyby moim zdaniem najlepiej wydane pieniądze na testy.

A co do logowania: http://www.jinspired.com/site/lies-damned-lies-and-log... - polecam :)Ten post został edytowany przez Autora dnia 13.08.13 o godzinie 21:33

Temat: Czy jeden test powinien testować jedną rzecz?

Michał Z.:

Co chciałem uzyskać? A no dowiedzieć się jak inni łapią równowagę między wieloma obszarami, na które można wydać kasę w projekcie. Nie chodzi o to, czy testować a jak to robić, żeby było efektywnie.

nie można było tak od razu precyzyjnie się wysławiać tylko się zaraz obrażać ;), moja subiektywna hierarchia "efektywności" poświęconego czasu / budżetu na testy (zakładając typową aplikację server side) od najbardziej efektywnych (w rozumieniu więcej czasu na testy => mniejsza ilość bugów = wieksza satysfakcja klienta) do mniej:

testy integracyjne / akceptacyjne wysokiego poziomu (Selenium? BDD?)

dopiero gdy budżet pozwoli oprócz testów akceptacyjnych / integracyjnych na coś więcej to warto zaplanować w większym stopniu w testy jednostkowe (idealistyczne TDD), tak wiem że to kontrowersyjna teza ale jak jest nóż na gardle to wolę mieć większe pokrycie testami akceptacyjnymi niż jednostkowymi

testy jednostkowe -> przydają się głownie gdy inwestycja będzie długoutrzymywana (lata) i będzie często refaktorowana, najbardziej przydatne dla własnych produktów lub przy długofalowej współpracy z klientem

Stawianie sprawy, że testy mają być

traktowane jak kod produkcyjny - nie jest efektywne. No, przynajmniej ja to tak widzę. Sporo zależy od projektu, klienta... Co najwyżej - może się okazać, że przy sprzyjających okolicznościach będzie efektywne.

na krótką metę zgadzam się, wydłużają czas dostarczenia funkcjonalności. Na dłuższą metę jednak umożliwiają pracowanie w warunkach jako takiej przewidywalności i kontrolowanego poziomu jakości przynajmniej w większości typowych aplikacji biznesowych. Nie wspominając o samopoczuciu członków zespołu.

Temat: Czy jeden test powinien testować jedną rzecz?

Jarosław S.:

dopiero gdy budżet pozwoli oprócz testów akceptacyjnych / integracyjnych na coś więcej to warto zaplanować w większym stopniu w testy jednostkowe (idealistyczne TDD), tak wiem że to kontrowersyjna teza

Niezbyt kontrowersyjna, zwłaszcza przy takich założeniach o jakich mowa.
Klasycy też uderzają w podobne tony. Pamiętam swoje pozytywne zdziwienie gdy na samym początku Growing Object-Oriented Software Guided by Tests przeczytałem parę zdań w tym stylu. A i swoją, jak to się teraz modnie określa, narrację, zaczynają Pryce i Freeman od napisania testu integracyjnego "z góry". Jednostkowe pojawiają się później. I wcale nie atakują ze wszystkich stron. Lodówkę można otwierać w każdym razie.
Dlaczego pozytywne zdziwienie? Trochę się bałem że "ci goście od JMock" będą bardziej "religijnie" podchodzili do jednostkowych. A tu - wcale nie. Plus dla nich ;-)

Temat: Czy jeden test powinien testować jedną rzecz?

Prawdę mówiąc - trochę zajęć mi wynikło i liczyłem, że dyskusja dalej się potoczy... No, może teraz, z nowym rokiem - szkolnym. :)

Testowanie wszystkiego nie ma sensu, brak testów też jest problemem. Moje zastanawianie się wynika z tego, że obserwuję owczy pęd - testować, testować, testować. Brak testów == nic nie da się powiedzieć o działaniu aplikacji. I różne inne podobne tezy. Na tych studiach, na SGH, zobaczyłem jak to wygląda od strony klienta. Z grubsza - w kontekście dyskusji - testy to jedno z całej masy rzeczy, na które można poświęcić zasoby. Poza kodem, który ma robić to co jest do zrobienia - można wydać kasę na clean code, na testowanie, na logowanie, na lepsze przemyślenie architektury. Ostatecznie każdy z elementów sprowadza się do złotówek na fakturze, albo godzinach spędzonych nad projektem. Wiadomo, że trzeba zachować balans, między tymi obszarami. Rafał wspominał, że takie rzeczy zależą od przeznaczenia. Jasne, nawet można mniej więcej określić takie zależności. Mój problem jest taki, że chciałbym więcej jak mniej... Rafał wspominał o długu technicznym. Dla mnie kluczowe jest jego dobre oszacowanie. Sonar używa m.in. pokrycia kodu testami do szacowania tego. Czyli jak mam niskie porycie testami jest spora szansa na problem, co ciekawe wyrażona w dniach pracy. Problem jest taki, że strasznie to rozmyte. W dużej mierze opiera się na tym, że programista wiedział co robił i robił to zgodnie z regułami. Chciałbym, żeby maszyna sprawdzała, czy oszukuję... Albo też jak zrobię testy geterów / seterów - mam jakieś tam pokrycie, które kompletnie nic nie wnosi... wiem ile wiedziałem, czas stracony, a co ciekawe - dług techniczny jest mniejszy. I w to nie wierzę.

Programista widzi swój kawałek i twierdzi, że to jest najważniejsze. Bo ktoś w mądrej książce napisał? Pewnie dziwny jestem, ale lubię wiedzieć dlaczego. Bo jak dostanę projekt bez testów to zobaczę? No - zobaczyłem wiele razy. Wcale nie wiem, czy utrzymywanie testów kosztowałoby mniej niż to co poświęciłem na przejęcie takiego projektu... Nie chodzi mi o spieranie się, albo udowadnianie komuś czegoś. Chciałbym się dowiedzieć jak sobie radzić z szacowaniem kosztów w takich sytuacjach. Kiedy dalsze pisanie testów jednostkowych ma sens, a kiedy nie. No i oczywiście - architektura, testy, logowanie, clean code - wszystko jest potrzebne. Zastanawiam się tylko jak określić ile tych testów ma być, co testować, żeby było efektywnie.

@Adrian. Zgoda, trzeba myśleć jak się coś robi. No, ale jak określić elementy krytyczne? Czy same testy integracyjne nie wystarczą? Śpieszę z odpowiedzią zanim zostanę źle zrozumiany. :)
Jak mam wybór w projekcie stawiam na testy integracyjne. Co do testów jednostkowych - powinna być infrastruktura do ich uruchamia - jenkins, czy coś, ale na początek bez testów jednostkowych. Kod trzeba pisać tak, żeby się potem dało testować, ale nie jestem fanem tdd. Czyli piszę kod z wydzielaniem tego, co zależy od czasu, czy tam jest losowe, ale nie testuję wszystkiego jak leci.
Testy jednostkowe - IMVHO - powinny obejmować kod, który jest używany przez parę miejsc. Zwykle trzeba mieć kontrolę nad kontraktem... Modelu nie testuję, chyba że jest tam coś do testowania - explicite.
Jak coś jest robione inaczej niż przewiduje framework - też trzeba testować, bo takie rzeczy lubią się rozjeżdżać.
Bugi w kodzie warto obskoczyć testem. Raz, bo tak łatwiej debugować, a dwa, bo powtarzające się bugi wpływają na wizerunek zespołu... Z czasem samo wychodzi gdzie są problemy, wtedy można jakoś testy poukładać. No, ale najpierw trzeba mieć co układać.

No, albo jeszcze inaczej. Jim Highsmith kiedyś napisał/powiedział, że agile jest wtedy, kiedy struktur jest dokładnie tyle, że projekt się nie zawala. Więcej struktur i projekt staje się skostniały, mniej i się zapada. Podobnie chciałbym z testami.