Metody tworzenia oprogramowania oparte o testowanie

Odpowiedz Nowy wątek
2011-07-25 09:56
Toffine
0

Najpierw powiem, że zaczynam się uczyć ciekawszych metod programowania i staram się je wykorzystać w praktyce w moich projekcikach "edukacyjnych" :)

Chciałbym poruszyć sprawę tworzenia oprogramowania które jest oparte o testowane. Mam tu na myśli np. Test Driven Development czy programowanie ekstremalne. Interesuje mnie np. to, czy faktycznie opłaca się najpierw robić testy a dopiero potem pisać kod pod testy? Pewnie nie jest to zalecane we wszystkich projektach, w szczególności tych mniejszych.

To co mnie interesuje - to kiedy warto stosować te metody programowania?
Jeśli macie jakieś ciekawe źródła na ten temat to też poproszę :)

Pozostało 580 znaków

2011-07-25 13:48
1

Testy mają przyspieszyć pracę i ułatwić wprowadzanie zmian. Ja do tego podchodzę tak, że w funkcji, która np. przyjmuje dane od użytkownika i po prostu zapisuje je w bazie nie ma za bardzo sensu testować, natomiast jeśli w funkcji występują jakieś obliczenia czy inne przetwarzanie danych, to warto zacząć od napisania testów.

Pozostało 580 znaków

2011-07-25 21:47
0

Zapoznaj się najpierw z modelami wytwarzania oprogramowania (np. model V, który oparty jest na testowaniu każdego etapu wytwarzania oprogramowania). W teorii testy powodują, że aplikacja przekazana klientowi powinna być w znacznym stopniu wolna od błędów. Niestety pisanie testów znacząco spowalnia programowanie (jeśli programuje się w pojedynkę i robi się to intensywnie, w innych przypadkach testy są wskazane). Jak robi się testy to trzeba wykonać podwójną robotę. Raz pisze się kod programu a później pisze się kod do testów.

Jeśli decydujesz się na robienie testów to są dwa podejścia:

  • najpierw piszesz kod a później testy
  • najpierw piszesz testy a później kod (np. red green test)

Pozostało 580 znaków

2011-07-25 23:05
0
wafcio napisał(a)

Niestety pisanie testów znacząco spowalnia programowanie

Nie powiedziałbym tak. Spowalnia jedynie prędkość pisania kodu właściwego programu, natomiast pozwala zaoszczędzić czas debugowania i szukania błędów, w ostatecznym rachunku, przy odpowiednim poziomi złożoności testowanych funkcji zawsze będzie zysk czasowy.

Jeśli decydujesz się na robienie testów to są dwa podejścia:

  • najpierw piszesz kod a później testy
  • najpierw piszesz testy a później kod (np. red green test)

Najpierw testy, potem kod. W drugą stronę to już nie jest TDD.
O to chodzi, żeby najpierw określić dla jakich danych jakie wyniki ma zwrócić funkcja (ze szczególnym uwzględnieniem warunków brzegowych), a potem napisać kod to realizujący. Odwrotnie będzie to mniej wydajne i bardziej błędogenne.

Pozostało 580 znaków

2011-07-26 09:17
Kewer
0

Ja bym się jednak trzymał zasady, że TDD należy stosować tylko w większych projektach. No i nie ma się co oszukiwać - programowanie z użyciem testów ma swoje wady, ale też mocne zalety - dlatego przecież się z tego korzysta.

Co do źródeł to polecam artykuł w tematyce testowania, a właściwie serię artykułów http://msdn.microsoft.com/pl-[...]/test-driven-development.aspx

Pozostało 580 znaków

2011-07-27 10:45
Toffine
0

Dzięki za źródło i Wasze porady. A jeśli chodzi o testowanie w Visual Studio, widzę że sporo kodu do testów generuje się automatycznie. Jak programowałem w Javie to w javowych ide wyglądało to podobnie, tylko nie trzeba było tworzyc nowych projektów. Czy w Visual Studio testy są właśnie jako oddzielne projekty?

Pozostało 580 znaków

2011-07-27 12:41
0
Toffine napisał(a)

Czy w Visual Studio testy są właśnie jako oddzielne projekty?

Jasne, gdyby było inaczej to byłoby to trochę bez sensu. :)

Pozostało 580 znaków

2011-07-27 14:46
0

Pisanie testów wydłuża pierwszą fazę projektu, ale oszczędzasz na przygotowywaniu fixów i klient mniej wkur..... Więc to co zaoszczędzisz na pisaniu testów, stracisz później.
Tak jak Somekind jestem za tworzeniem testów raczej do kodu wykonujące obliczenia, wykonującego jakieś walidacje biznesowe, czy generalnie do testowania logiki biznesowej, niż do każdej metody w projekcie, która np. tylko pobiera wartości z konfiguracji, czy z bazy.

Pozostało 580 znaków

2011-08-04 18:48
0
Toffine napisał(a)

Chciałbym poruszyć sprawę tworzenia oprogramowania które jest oparte o testowane. Mam tu na myśli np. Test Driven Development czy programowanie ekstremalne. Interesuje mnie np. to, czy faktycznie opłaca się najpierw robić testy a dopiero potem pisać kod pod testy? Pewnie nie jest to zalecane we wszystkich projektach, w szczególności tych mniejszych.

Jasne że warto! Pomyśl wolisz najpierw pisać, potem testować, a w końcu myśleć co chcesz osiągnąć, czy pomyśleć co chcesz osiągnąć, napisać testy weryfikujące zgodność wymagań i tworzenie kodu dopóki testy nie przechodzą pomyślnie? Jeżeli wiesz czego oczekujesz jest to najlepsza droga do osiągnięcia tego.

TDD jest jedną z metodyk pisania testów, inną coraz bardziej popularniejszą jest BDD (Behavior Driven Development), którą swoją drogą polecam, zapoznaj się a potem pisz w czym Ci lepiej.

Ja preferuję BDD, choćby ze względu na fakt że jest to również często dobra dokumentacja wymagań, oczywiście najpopularniejszym zastosowaniem testów jest weryfikacja - komu by się ręcznie chciało pisać kod testujący albo programy do tego potrzebne? ; ) TDD stosuję gdy piszę mały fragment którego nie mam zamiaru na razie integrować nigdzie indziej, szybciej się pisze.

Pozostało 580 znaków

2011-08-20 12:09
0

Jak dla mnie - niewarto. Prostymi testami, które wymyśli człowiek, nie pokryje się wszystkich możliwych dziwnych przypadków, dla których dana funkcja nie zadziała. O wiele lepsze byłyby "testy" napisane w OCLu.


"Robienie w Javie moge porównac do spuszczania wody w kiblu za pomoca wiadra z wodą przyniesioną ze studni zza 7 gór, którą się dodatkowo samemu wykopało łyżeczką do słodzenia herbaty."

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0