Komentarze do wpisu 'Behaviour Driven Development'

By: Stifflog PL – Behaviour Driven Development – programowanie - dowiedz się więcej!

Mon, 03 May 2010 22:34:39 +0000

[...] Więcej: Stifflog PL – Behaviour Driven Development [...]

By: zuras

zuras — Tue, 16 Jan 2007 23:02:13 +0000

Drodzy koledzy, testy funkcjonalne i modulowe sie nie wykluczaja a wrecz przeciwnie - Uzupelniaja sie! To nie moze byc tak ze ktores sa lepsze. Moim zdaniem powinno sie stosowac obydwie metody (i nie tylko te).
A odnosnie wypracowania sztywnego to bardzo mi sie podoba. Testy modulowe czesto staja sie zbyt syntetyczne i oderwane od rzeczywistosci. Nie sprawdzaja rzeczywistych sytuacji a w skrajnych sytuacjach sa ‘odwalane’ aby tylko byly bo kod nie przejdzie inspekcji jak nie bedzie do niego testow. Testy modulowe wymagaja zaangazowania i wiary w ich skutecznosc.

Pozdro

By: sztywny

sztywny — Wed, 29 Nov 2006 06:05:52 +0000

Poprzez ów “korespondencje” rozumiem takie układanie testów, żeby ich struktura odzwierciedlała strukturę kodu, a to już dawno “wyszło z mody”. Oczywiście uwzględniamy to co jest w środku, ale nie skupiamy się na tym jak to coś jest zbudowane, ale raczej na tym jak dany kawałek kodu powininen się zachowywać w danej sytuacji.

Poprzez testowanie funkcjonalne najczęściej rozumie się testy nie mające z kodem zupełnie nic wspólnego, w których jakiś automat np. wpisuje jakiś tekst w nasze input boxy i patrzy co się dzieje. Z drugiej strony widziałem już tą definicje odniesioną do wielu bardzo różnych rzeczy…

Ostatni przykład korzysta z mock objects w wydaniu BDD.

By: Michał Kwiatkowski

Michał Kwiatkowski — Tue, 28 Nov 2006 21:34:39 +0000

Nie zgodziłem się dokładnie z tym jednym zdaniem:

Doświadczeni testerzy robią zupełnie co innego - testują poszczególne zachowania i grupy zachowań programu, nie skupiając się na korespondencji pomiędzy testami a wewnętrzną strukturą kodu.

Dla mnie testowanie zachowań programu bez uwzględnienia tego co jest w środku to jest właśnie testowanie funkcjonalne. Testowanie modułowe zakłada znajomość wnętrza systemu (jak chociażby nazwy metod), jak i połączeń w środku (co czasami wymaga skorzystania z tzw. mock objects, by rzeczywiście przetestować pojedynczy kawałek kodu). Dlatego zdanie powyższe zrozumiałem jako “Doświadczeni testerzy testują tylko funkcjonalnie”. A z tym ciężko się zgodzić.

By: sztywny

sztywny — Tue, 28 Nov 2006 18:38:15 +0000

Racja.

By: dr_bonzo

dr_bonzo — Tue, 28 Nov 2006 18:33:18 +0000

Znowu ja, wiem czego braklo: opisania kontekstow jako stanow/kontekstow, ktore specyfikujemy, np. niedostepny feed, dostepny feed, bledny xml feeda, itp.

By: sztywny

sztywny — Tue, 28 Nov 2006 12:35:53 +0000

Byka ortograficznego poprawiłem, a @newses niech już sobie zostanie jak jest :D

By: dr_bonzo

dr_bonzo — Tue, 28 Nov 2006 11:41:31 +0000

Dobre wyjasnienie TDD i BDD i ich roznic.

Doczepie sie tylko do @newses :D powinno byc @news ale skoro stosujemy prawo najmniejszego zaskoczenia (LOLA) to nie znajac dobrze slownictwa/gramatyki angielskiego widze ze to liczba mnoga i tablica :)

By: Rrrodrigo

Rrrodrigo — Tue, 28 Nov 2006 09:22:41 +0000

Pułapka czyha a nie czycha ;-) Poza tym nie mam się do czego przyczepić :-(

By: sztywny

sztywny — Tue, 28 Nov 2006 06:15:12 +0000

Wcale nie namieszałem. Specjaliści od testów modułowych (przez test modułowych rozumiem wszystko co jest pisane są pisane za pomocą frameworku do pisania testów modułowych np. runit czy junit, inne rozróżnienia są dość dziwne i mgliste) nie zalecają pisania jednego testu na metodę i nie chodzi wcale o corner cases. Jeśli obejrzysz prezentacje Dave’a Astelsa który jest jakimś tam autorytetem jeśli chodzi o testowanie, to będziesz tam miał jeden z argumentów - jeśli piszesz test per metodę, to w momencie w którym refaktorujesz musisz też przepisywać swój test. Ba, zaleca się nawet tylko jedną asercję na test:

http://www.artima.com/weblogs/viewpost.jsp?thread=35578

Jeśli nie wierzysz temu konkretnemu panu, podobne rzeczy znajdują się w każdej książce o TDD, niektóre z nich także można kupić w Polsce (ostatnio kupiłem np. “Programowanie Ekstremalne w C#” bodajże, ale właściwie jest to książka o testowaniu).

Testowanie funkcjonalne w rodzaju tego realizowanego przez Selenium jest zupełnie czymś innym i nie o nim mówimy.