Metody tworzenia oprogramowania oparte o testowanie

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ę :)

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.

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

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-pl/library/test-driven-development.aspx

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?

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. :)

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.

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.

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.

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