Temat: TDD, testowanie i inne takie

"Lekki" off-topic się zrobił w temacie Refaktoryzować, czy nie :)
Proponuję więc kontynuować (o ile jeszcze jest co kontynuować) dyskusję na temat testów i wszystkiego, co z nimi związane w tym wątku:)

To tak na rozgrzewkę:
Czy uważacie, że testy jednostkowe mają sens w przypadku aplikacji, które powstają na bazie gotowego projektu, czy może wystarczą testy akceptacyjne?
Z jednej strony zawsze istnieje szansa, że coś się zmieni (wiem, że nie powinno, ale w praktyce różnie bywa:), może będzie trzeba coś dodać w przyszłości i wtedy ewentualne testy mogą pomóc przy nie wprowadzaniu błędów.
Patrząc jednak z innego punktu, to mamy przecież całą gamę testów akceptacyjnych, które pokażą nam, czy coś po drodze nie zepsuliśmy (też się nie powinno zdarzyć, ale czasem bywa inaczej:).

Kiedy decydujecie się na testy? I jakie? Czy macie jakieś kryteria, które pomagają Wam podjąć decyzję, że już się opłaca/jeszcze się nie opłaca pisać testów?Sebastian Malaca edytował(a) ten post dnia 15.10.12 o godzinie 21:12

Temat: TDD, testowanie i inne takie

<pomyłka:P>Sebastian Malaca edytował(a) ten post dnia 15.10.12 o godzinie 21:11

Temat: TDD, testowanie i inne takie

z mojej perspektywy pytanie "podchwytliwe", jeżeli napisze testy odbiorowe tak, żeby użycie oprogramowania wymagał użycie "każdej klasy" to co wnoszą testy TDD?

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
z mojej perspektywy pytanie "podchwytliwe", jeżeli napisze testy odbiorowe tak, żeby użycie oprogramowania wymagał użycie "każdej klasy" to co wnoszą testy TDD?

Testy to testy, a TDD to jest technika tworzenia oprogramowania. Zakładam, że pisząc 'testy TDD' miałeś na myśli testy jednostkowe, czy tak?

W takim wypadku pytanie raczej powinno brzmieć: czy wnoszą cokolwiek?
Osobiście uważam, że to zależy od prawdopodobieństwa zmian i ewentualnej rozbudowy aplikacji. Im to prawdopodobieństwo jest wyższe, tym bardziej bym się skłaniał do pisania testów, ponieważ tym bardziej czas włożony w ich napisanie może się opłacić w przyszłości (i mi i, przede wszystkim, klientowi).

Jeżeli jednak zależy nam "tylko" na działającej aplikacji i nie obchodzi nas to, co będzie potem (dość typowe, niestety, podejście), to takie testy bym sobie podarował, ponieważ ani dla mnie ani dla klienta nie mają one żadnej wartości. Twoje testy byłyby wystarczające, ponieważ gwarantowałyby, że aplikacja spełnia wymagania (a przynajmniej wszystkie przetestowane scenariusze).

Temat: TDD, testowanie i inne takie

to ja pozwolę sobie tutaj odpowiedź na komentarz z poprzedniego wątku:

Sebastian Malaca:

dla mnie TDD:
- nie zajmuje dużo więcej czasu bo czas poświęcony na przygotowanie dobrych testów szybko zwraca się, bo nie traci się czasu na poprawianie błędów i debugowanie (błędy spowodowane literówkami albo copypastą)

Błędy spowodowane przez copy-paste? To ja polecam pomyśleć zanim popełnisz nie błąd, ale właśnie copy-paste, bo zazwyczaj (zawsze?) można to rozwiązać w inny sposób.

nie chodziło mi oczywiście o copy-paste funkcji, wiadomo, że to jest złe, chodziło mi o sytuacje kiedy ma to sens, np. kopiowanie pojedynczej linijki, która ma się powtórzyć z jakąś drobną zmianą
(przykład new Company(name: "Company1").save() - czasem trzeba coś takiego wstawić w kodzie testu, skopiować 3x i zmienić tylko cyferkę na końcu nazwy)

- podnosi istotność pisania testów jednostkowych na równi z kodem właściwym,

???

>
miałem na myśli to co niżej - kod testów staje się ważną częścią całości, bo gwarantuje poprawność działania, klient tak naprawdę nie musi wiedzieć że te testy powstają, są one częścią developmentu i wydłużają czas pracy powiedzmy o 10-20% (w stosunku do niepisania testów wcale) ale jeśli dzięki nim nie tracimy czasu na debugowanie i łatanie błędów, które mogą (a właściwie nie muszą!) wyjść gdzieśtam później już przy testach "manualnych" to według mnie może to być nawet oszczędność czasu

testy są równoprawnym kodem aplikacji, choć nie używanym produkcyjnie ale zapewniajacym jakość

Nie masz racji. Testy są dla Ciebie, klienta mało obchodzi, czy testujesz, czy nie, jeżeli dostaje działające oprogramowanie.

>
jw., działające oprogramowanie zagwarantowane przez testy, jeśli pracujesz w małym zespole gdzie nie ma osobnej osoby od przeklikiwania scenariuszy testowych, to unit testy są podstawowym QA a zarazem bardzo skutecznym

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
Testy to testy, a TDD to jest technika tworzenia oprogramowania. Zakładam, że pisząc 'testy TDD' miałeś na myśli testy jednostkowe, czy tak?

W takim wypadku pytanie raczej powinno brzmieć: czy wnoszą cokolwiek?
Osobiście uważam, że to zależy od prawdopodobieństwa zmian i ewentualnej rozbudowy aplikacji.

sytuacja "idealna" do przemyśleń, dobrze zaprojektowana klasa zostaje, nowe rzeczy to nowe klasy, złe klasy są refaktoryzowane, każda klasa jest przemyślana,

co tu wnosi TDD?

Temat: TDD, testowanie i inne takie

Kamil Mikołajczyk:
miałem na myśli to co niżej - kod testów staje się ważną częścią całości, bo gwarantuje poprawność działania, klient tak naprawdę nie musi wiedzieć że te testy powstają, są one częścią developmentu i wydłużają czas pracy powiedzmy o 10-20% (w stosunku do niepisania testów wcale)

Jeżeli aplikacja jest nietrywialna, to będziesz zmuszony testować wiele metod, których testy mogą zajmować nieraz więcej czasu niż implementacja metody.

Ja bym był skłonny stwierdzić, że testowanie (mówię o testach jednostkowych, bo moim zdaniem, jedynie je można rozważać jako opcjonalne) wydłuża czas pracy odrobinę (?) dłużej, chociaż nie chciałbym rzucać liczbami, które opierają się na moich doświadczeniach. Tutaj przydałyby się jakieś statystki.

Jakiekolwiek by jednak te liczby nie były, to i tak uważam, że przed podjęciem decyzji o tym, czy pisać testy, czy nie powinniśmy się zastanowić, czy ewentualne korzyści są rzeczywiście wystarczające.

jeśli dzięki nim nie tracimy czasu na debugowanie i łatanie błędów, które mogą (a właściwie nie muszą!) wyjść gdzieśtam później już przy testach "manualnych" to według mnie może to być nawet oszczędność czasu

Testy jednostkowe nie dają Ci gwarancji, że całość zadziała. Nawet jeżeli wszystkie elementy będą doskonałe, to ich połączenie może nie dać takiego wyniku, jaki chcesz otrzymać.
I teraz pytanie - czy posiadając pełny projekt aplikacji te testy rzeczywiście Ci się przydadzą? W końcu ktoś poświęcił czas na rozwiązanie problemu, więc czy testy akceptacyjne nie byłyby wystarczające?

działające oprogramowanie zagwarantowane przez testy,

Nawet biorąc pod uwagę każdy rodzaj testów, to nie są one żadną gwarancją. Jeżeli przechodzą, to znaczy, że aplikacja zachowuje się poprawnie przy przetestowanych (skończonych i nigdy wszystkich) scenariuszach.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
sytuacja "idealna" do przemyśleń, dobrze zaprojektowana klasa zostaje, nowe rzeczy to nowe klasy, złe klasy są refaktoryzowane, każda klasa jest przemyślana,

co tu wnosi TDD?

Jeżeli piszesz o refaktoryzacji (zakładamy, że jest duże prawdopodobieństwo jej wystąpienia), to TDD przydaje się. Dzięki tym wszystkim testom, które napisane zostały wcześniej, masz pewność, że podczas refaktoryzacji czegoś nie zepsujesz.
Takie wpadki się niestety zdarzają (przemęczenie, deadline itp.) nawet najlepszym i tutaj TDD sprawdza się znakomicie.
A im większy projekt, tym większe korzyści.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Sebastian Malaca:
Testy to testy, a TDD to jest technika tworzenia oprogramowania. Zakładam, że pisząc 'testy TDD' miałeś na myśli testy jednostkowe, czy tak?

W takim wypadku pytanie raczej powinno brzmieć: czy wnoszą cokolwiek?
Osobiście uważam, że to zależy od prawdopodobieństwa zmian i ewentualnej rozbudowy aplikacji.

sytuacja "idealna" do przemyśleń, dobrze zaprojektowana klasa zostaje, nowe rzeczy to nowe klasy, złe klasy są refaktoryzowane, każda klasa jest przemyślana,

co tu wnosi TDD?

Wrzucając wszystkie nowe rzeczy do nowych klas, będziemy w końcu zmuszeni do złamania zasady "DRY". W konsekwencji, przy dużej ilości zmian, nowych rzeczach, nasz kod będzie rozrastał się do niebotycznych rozmiarów. Setki razy miałem już sytuację że wolałem dodać jakąś metodę bo bałem się zmieniać inną.
Natomiast mając testy jednostkowe, możemy śmiało zmieniać nasz kod, testy i tak wyłapią miejsca gdzie zmiany te powodują problemy. W konsekwencji mamy mniej kodu, projekt jest łatwiejszy do opanowania.

Temat: TDD, testowanie i inne takie

Janusz Matyja:
Wrzucając wszystkie nowe rzeczy do nowych klas, będziemy w końcu zmuszeni do złamania zasady "DRY".

Ale takie działanie może być spowodowane jedynie przez nie zastanowienie się nad problemem. W innym wypadku wątpię, że będziesz zmuszony do kopiowania kodu, który kopiowany być nie powinien.

przy dużej ilości zmian, nowych rzeczach, nasz kod będzie rozrastał się do niebotycznych rozmiarów. Setki razy miałem już sytuację że wolałem dodać jakąś metodę bo bałem się zmieniać inną.

W takim wypadku postarałbym się usunąć powód strachu, a nie dodawać kolejną metodę, ponieważ to, co budzi Twoje obawy, to z pewnością kod, który powinien być lepiej zaimplementowany.

Natomiast mając testy jednostkowe, możemy śmiało zmieniać nasz kod, testy i tak wyłapią miejsca gdzie zmiany te powodują problemy. W konsekwencji mamy mniej kodu, projekt jest łatwiejszy do opanowania.

Tu się zgadzam. No może poza ilością tego kodu:P

Temat: TDD, testowanie i inne takie

Sebastian Malaca:

Janusz Matyja:
Wrzucając wszystkie nowe rzeczy do nowych klas, będziemy w końcu zmuszeni do złamania zasady "DRY".

Ale takie działanie może być spowodowane jedynie przez nie zastanowienie się nad problemem. W innym wypadku wątpię, że będziesz zmuszony do kopiowania kodu, który kopiowany być nie powinien.

przy dużej ilości zmian, nowych rzeczach, nasz kod będzie rozrastał się do niebotycznych rozmiarów. Setki razy miałem już sytuację że wolałem dodać jakąś metodę bo bałem się zmieniać inną.

W takim wypadku postarałbym się usunąć powód strachu, a nie dodawać kolejną metodę, ponieważ to, co budzi Twoje obawy, to z pewnością kod, który powinien być lepiej zaimplementowany.

Natomiast mając testy jednostkowe, możemy śmiało zmieniać nasz kod, testy i tak wyłapią miejsca gdzie zmiany te powodują problemy. W konsekwencji mamy mniej kodu, projekt jest łatwiejszy do opanowania.

Tu się zgadzam. No może poza ilością tego kodu:P

Powód strachu jest jeden: metoda wykorzystywana jest w wielu miejscach aplikacji. Bez testów jednostkowych musiałbym przeklikiwać się przez te wszystkie miejsca, a i tak nigdy nie jestem pewien czy sprawdziłem wszystkie możliwości. Co innego jeśli mam napisane testy.

Temat: TDD, testowanie i inne takie

Janusz Matyja:
Powód strachu jest jeden: metoda wykorzystywana jest w wielu miejscach aplikacji.

Jeżeli jest to jakaś metoda, która nie dotyka logiki biznesowej, to wydaje mi się, że odpowiednia jej implementacja może ustrzec Cię przed tym strachem, a jeżeli jest to metoda, która jednak tej logiki dotyczy, to w takim wypadku powinieneś zastanowić się, czy nie ma zbyt wielkiej zależności pomiędzy klasami.

Bez testów jednostkowych musiałbym przeklikiwać się przez te wszystkie miejsca, a i tak nigdy nie jestem pewien czy sprawdziłem wszystkie możliwości. Co innego jeśli mam napisane testy.

To akurat prawda. Z tym, że testów nie powinno się traktować, jako lek na strach przed zmianami. Tym lekiem powinna być jakość Twojego kodu:)

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
To tak na rozgrzewkę:
Czy uważacie, że testy jednostkowe mają sens w przypadku aplikacji, które powstają na bazie gotowego projektu, czy może wystarczą testy akceptacyjne?

Zależy co masz na myśli.
Testy jednostkowe nie muszą być tożsame z rozwiązaniem "xUnit" - niekoniecznie są zautomatyzowane.
Mogą być realizacją podejścia white-box testing.

W niektórych środowiskach (np. midrange) rozwiązania xUnit mogą w ogóle nie być dostępne.
Ale testy jednostkowe zawsze należy robić.
Choćby po to żeby prześledzić czy program pracuje tak jak nam się wydaje, że powinien pracować. Użytkownik może nie mieć szansy tego stwierdzić.

Temat: TDD, testowanie i inne takie

Janusz Matyja:

sytuacja "idealna" do przemyśleń, dobrze zaprojektowana klasa zostaje, nowe rzeczy to nowe klasy, złe klasy są refaktoryzowane, każda klasa jest przemyślana,

co tu wnosi TDD?

Wrzucając wszystkie nowe rzeczy do nowych klas, będziemy w końcu zmuszeni do złamania zasady "DRY".

nie koniecznie. Dobry projekt po pierwsze separuje dziedzinę (istnienie i zachowania elementów dziedzinowych) od usług systemu (serwisów korzystających z dziedziny).

Nowa funkcjonalność to nowa klasa (lub operacja) odpowiedzialna za realizację przypadku użycia. W modelu dziedziny to raczej niczego nie zmieni chyba, że go poszerzymy ale nie zmienimy.

Np. w modelu dziedziny będzie klasa FakturaVAT, RepozytoriumFatur i klasa TworzenieNowychFaktur, pierwsza modeluje obiekt biznesowy druga nimi zarządza, trzecia wie o tym jak faktura powstaje. System pierwotnie ma funkcjonalność: fakturowanie sprzedaży, czyli do tych klas (komponentów) była dodana klasa obsługująca scenariusz przypadku użycia "fakturowanie sprzedaży".

Jeżeli rozwój systemu polega na dodaniu nowego przypadku użycia RaportySprzedaży, dodamy nową klasę go realizującą i podłączymy do RepozytoriumFaktur, ewentualnie dodamy nowe operacje do klasy Repozytorium.

Nie ma tu nigdzie mowy o zmianach, jest tylko rozbudowa. Przemyślany projekt nie będzie wymagał żadnych zmian, projekt zły faktycznie może wymagań "przeróbek" i to nie raz dużych.

(zasady DRY tu nie łamiemy)

Natomiast mając testy jednostkowe, możemy śmiało zmieniać nasz kod, testy i tak wyłapią miejsca gdzie zmiany te powodują problemy. W konsekwencji mamy mniej kodu, projekt jest łatwiejszy do opanowania.

z powyższego wynika to co sugerował Jakub: "złe projekty" (dużo przeróbek w przyszłości) faktycznie wymagają takich testów z powodu opisanego właśnie powyżej, "dobry projekt" po protu rozbudowujemy i tak się da, nie tylko Jakub, ja także takie mam ...Jarek Żeliński edytował(a) ten post dnia 16.10.12 o godzinie 13:32

Temat: TDD, testowanie i inne takie

Janusz Matyja:
Powód strachu jest jeden: metoda wykorzystywana jest w wielu miejscach aplikacji.

klikać??? ok, ale dlaczego jest implementowana w więcej niż jednej klasie???

Temat: TDD, testowanie i inne takie

Piotr L.:
Ale testy jednostkowe zawsze należy robić.
Choćby po to żeby prześledzić czy program pracuje tak jak nam się wydaje, że powinien pracować. Użytkownik może nie mieć szansy tego stwierdzić.

Użytkownik może i nie, ale jeżeli mamy wystarczającą ilość scenariuszy, to czy testy akceptacyjne nie są wystarczające? Wtedy wiemy, że program pracuje zgodnie z wymaganiami.
I po co nam wtedy testy jednostkowe? Po to tylko, żeby po drodze nie popełnić błędu? Zakładam, że jeżeli nad jakością kodu czuwa cały zespół (review, pair-programming itp.), to testy, które mają na celu ustrzeżenie nas przed własnymi błędami nie są koniecznością.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Janusz Matyja:
Powód strachu jest jeden: metoda wykorzystywana jest w wielu miejscach aplikacji.

klikać??? ok, ale dlaczego jest implementowana w więcej niż jednej klasie???

Z tego, co zrozumiałem to Januszowi chodzi o to, że są używane, a nie implementowane w wielu miejscach. W takim wypadku problemem może być to, że jest zbyt wiele zależności pomiędzy klasami.Sebastian Malaca edytował(a) ten post dnia 16.10.12 o godzinie 14:52

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
W takim wypadku problemem może być to, że jest zbyt wiele zależności pomiędzy klasami.

co też jest błędem projektowym :)

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
co tu wnosi TDD?

Dużo wnosi. TDD to koncepcja, która mówi - zanim zaczniesz pisać kod napisz testy, które zweryfikują jego zgodność z wymaganiami. Bez względu na to czy mówimy o testach na poziomie jednostkowym czy funkcjonalnym.
Jeżeli tworzymy testy do istniejącego systemu zawsze jesteśmy skazani na sugerowanie się jego funkcjonalnością w opracowaniu testów. TDD zmusza nas, abyśmy konstruując testy opierali się tylko i wyłącznie na wymaganiach. To dobra praktyka - choć niełatwa do wdrożenia - szczególnie na wyższym poziomie abstrakcji niż testy jednostkowe.

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:
Dużo wnosi. TDD to koncepcja, która mówi - zanim zaczniesz pisać kod napisz testy, które zweryfikują jego zgodność z wymaganiami.

Co tu nazywamy wymaganiem?