Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Witam,

W najbliższym czasie zamierzam przeprowadzić eksperyment TDD na
studentach uczelni technicznej. Eksperyment ma na celu wykazanie (lub
nie) różnicy w jakości kodu kiedy napiszemy test przed kodem.
Myślę, że wyniki takiego eksperymentu mogą być ciekawe dla managmentu a zaspokoję przy tym własną ciekawość
Czy macie jakieś pomysły jak taki eksperyment mógłby wyglądać w warunkach akademickich?(około godziny na kodowanie a problem musi mieć złożoność wystarczającą do zaobserwowania czegokolwiek innego niż losowe liczby)
Jakieś sugestie lub pomysły? Na razie chodzi mi po głowie zadanie polegające na napisaniu prostej gry np w kręgle albo rosyjskiej ruletki, tak żeby zachodziła jakaś hierarchia w klasach. Następne zmierzę zadany kod metrykami(ilość linii kodu, ilość błędów, głębokość zagnieżdzeń, ilość statycznych metod)
Z góry dzięki za wszelakie sugestie i pomysły


Kuba

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Ciężka sprawa. Godzina to bardzo niedużo czasu. Przychodzą mi do głowy standardowe problemy, które, od biedy, da się zaimplementować w tak krótkim czasie: jedzący filozofowie oraz system producent-konsument. Problemy te narzucają pewną strukturę obiektową dając zarazem sporą wolność w implementacji.

//edit: swoją drogą, ciekawe metryki. Raczej skłaniałbym się ku długości metod, ilości metod, ilości metod publicznych, ilości i rodzajowi powiązań między obiektami...Dariusz Wawer edytował(a) ten post dnia 13.09.10 o godzinie 19:43

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Kubo - z ciekawości - w jakim celu chcesz mierzyć ilość linii kodu, głębokość zagnieżdżeń, ilość statycznych metod, długości metod, ilości metod, ilości metod publicznych, ilości i rodzajowi powiązań między obiektami?

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Kuba Guzik:
Witam,

W najbliższym czasie zamierzam przeprowadzić eksperyment TDD na
studentach uczelni technicznej. Eksperyment ma na celu wykazanie (lub
nie) różnicy w jakości kodu kiedy napiszemy test przed kodem.
Myślę, że wyniki takiego eksperymentu mogą być ciekawe dla managmentu a zaspokoję przy tym własną ciekawość
Czy macie jakieś pomysły jak taki eksperyment mógłby wyglądać w warunkach akademickich?(około godziny na kodowanie a problem musi mieć złożoność wystarczającą do zaobserwowania czegokolwiek innego niż losowe liczby)
Jakieś sugestie lub pomysły?

Witam,

W godzinę raczej nic sensownego nie przeprowadzisz jakkolwiek może poniższa propozycja nasunie tobie jakieś inspiracje:

Wymyśl jakieś niebanalna acz nierozbudowane wymagania aplikacji nazwijmy je W1. Pierwsza grupa studentów ma 20-25 minut na zaimplementowanie tej grupy funkcjonalności. Następnie "aplikację" przejmuje druga grupa studentów, która ma 40 minut na zaimplementowanie drugiej grupy funkcjonalności W2. Na końcu sprawdzisz ile funkcjonalności z grupy W1 popsuli studenci stosujący TDD.

pzdr

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Przemysław Wardowski:
Kubo - z ciekawości - w jakim celu chcesz mierzyć ilość linii kodu, głębokość zagnieżdżeń, ilość statycznych metod, długości metod, ilości metod, ilości metod publicznych, ilości i rodzajowi powiązań między obiektami?

Ponieważ uważam, że skutkiem ubocznym stosowania TDD jest większa modularność kodu, czytelność, łatwość zmian, a przykładając ww. metryki mogę to zmierzyć. Pomijam aspekt psychologiczny TDD, tutaj ciężko o obiektywny werdykt i pomiar.

Paweł Włodarski:
Wymyśl jakieś niebanalna acz nierozbudowane wymagania aplikacji nazwijmy je > W1. Pierwsza grupa studentów ma 20-25 minut na zaimplementowanie tej grupy
funkcjonalności. Następnie "aplikację" przejmuje druga grupa studentów,
która ma 40 minut na zaimplementowanie drugiej grupy funkcjonalności W2. Na
końcu sprawdzisz ile funkcjonalności z grupy W1 popsuli studenci stosujący
TDD.

Z pewnością taki eksperyment miał by sens ale moim zdaniem nie w półtorej godziny, cała trudność wykazania wyższości/niższości TDD polega na tym, że firmy niechętnie pozwalają na zaglądanie we własny kod a badania na studentach mają ograniczenie czasowe i niekoniecznie przekładają się na praktykę zawodową.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Kuba Guzik:
W najbliższym czasie zamierzam przeprowadzić eksperyment TDD na
studentach uczelni technicznej. Eksperyment ma na celu wykazanie (lub
nie) różnicy w jakości kodu kiedy napiszemy test przed kodem.
Myślę, że wyniki takiego eksperymentu mogą być ciekawe dla managmentu a zaspokoję przy tym własną ciekawość
Czy macie jakieś pomysły jak taki eksperyment mógłby wyglądać w warunkach akademickich?(około godziny na kodowanie a problem musi mieć złożoność wystarczającą do zaobserwowania czegokolwiek innego niż losowe liczby)

Kiedyś brałem udział (od strony administracyjno-technicznej) w eksperymencie TDD oraz "pair programming" przeprowadzonym na Politechnice Wrocławskiej (całość zdaje się została opisana w tej książce przez prowadzącego zajęcia) - przy czym nie trwało to kilka godzin, a cały semestr :), włącznie ze specyficznymi uwarunkowaniami infrastruktury serwerowej (np. dostęp do repozytoriów kodu tylko w czasie zajęć laboratoryjnych, co miało potem pomóc w analizie postępów, itd.). Jak wspomniałem - "kaliber" znacznie większy niż planujesz, ale może znajdziesz tam coś przydatnego; całkiem możliwe też, że na http://www.e-informatyka.pl znajdziesz artykuły o podobnych eksperymentach, jak również wśród artykułów wspomnianego wykładowcy.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Witam ponownie,
Dzieki za liczne rady, mając je na uwadze ułożyłem plan przebiegu badania.
Zdecydowałem się na poszerzenie ekpserymentu na jak największa ilość osób. Uwazam, że im więcej uczetników tym bardziej wiarygodny będzie wynik.
Eksperyment odbędzie się w czwartek 2 grudnia 2010r.
w sali 429 budynek C2 o godzinie 18:00.
Do uczestnictwa wymagany jest własny komputer. Badanie będzie polegało na napisaniu prostej gry i wysłaniu źródeł w celu analizy odpowiednimi metrykami.
Biorąc udział w badaniu nauczymy się pracy z TDD, a ostatecznie dowiemy się czy warto stosować TDD w firmie.
Osoba która weźmie udział w eksperymencie i pochwali się kodem wysokiej jakości dostanie Power Balla :)

Informacje dostępne również na stronie: http://tddexperiment.heroku.com/

Serdecznie zapraszam.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

W grudniu odbył się eksperyment badający wpływ praktyki TDD na jakość kodu. Największym problemem okazała się frekwencja. Wiele osób nie mogło przyjść w określonym czasie.
Aby ułatwić uczestnictwo w eksperymentach i kontynuować badania utworzyłem zdalny eksperyment w którym łatwiej uczestniczyć.
Zachęcam do udziału: http://chequality.heroku.com/
Zadanie polega na pisaniu gdy w tetris'a. Powinno zająć nie więcej niż godzinę, a poza nauką TDD przyczyni się odpowiedzi na pytanie: Czy kod napisany metodą TDD jest wyższej jakości niż kod napisany standardowym podejściem Test-After Kuba Guzik edytował(a) ten post dnia 03.04.11 o godzinie 12:56

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Kuba Guzik:
W najbliższym czasie zamierzam przeprowadzić eksperyment TDD na
studentach uczelni technicznej. Eksperyment ma na celu wykazanie (lub
nie) różnicy w jakości kodu kiedy napiszemy test przed kodem.

Co moją testy do jakości kodu ?
Czy jest jakiekolwiek sensowne przełożenie jakości kodu na poprawność wyników jakie generuje ?

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

przyznaje ze nigdy nie widzialem jeszcze prawdziwego "idealnego" TDD w pracy :)
natomiast stosowalem podejscie w ktorym kod powstawal na biezaco wraz z testami, tj: na poczatku dwu tygodniowego sprintu decydujemy co ma byc zaimplementowane, kod zwlaszcza jezeli to cos niestandardowego powstaje najpierw jako proof of concept, nastepnie testy i refaktoryzacja, pozniej review i commit. Wszystko wspomagane przez ciagla integracje w wydaniu cross platform.

Wynik byl taki, ze poswiecajac nieco wiecej czasu na pisanie testow i refaktor dostawalismy stabilny produkt przy kazdym buildzie ktory zakonczyl sie sukcesem.

Feedback od uzytkownikow przewaznie pozytywny a ilosc critical bugow byla najczesciej rowna zero, jezeli juz gdzies byl blad to jakies niedorobki w interfejsie, natomiast sama logika dzialala dokladnie tak jak zostalo to okreslone w testach.

co do jakosci, mysle ze nie moze byc mowy o jakosci kodu jezeli nie ma testow. to ze cos jest napisane ladnie wcale nie oznacza ze dziala poprawnie, zarowno dla malych jak i duzych porcji danych. Do tego dochodza kwestie bledow kompilatorow czy samych srodowisk ktore nie sa mozliwe do wykrycia jezeli nie ma ciaglej integracji.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jakub Wojt:

Kuba Guzik:
W najbliższym czasie zamierzam przeprowadzić eksperyment TDD na
studentach uczelni technicznej. Eksperyment ma na celu wykazanie (lub
nie) różnicy w jakości kodu kiedy napiszemy test przed kodem.

Co moją testy do jakości kodu ?
Czy jest jakiekolwiek sensowne przełożenie jakości kodu na poprawność wyników jakie generuje ?

Najlepiej wytłumaczyć to empirycznie.

Najpierw zerknij sobie np. na metrykę http://en.wikipedia.org/wiki/Cyclomatic_complexity.

Napisz kod który będzie miał cyclomatic complexity powiedzmy 30 (gdzie zalecane jest nie więcej niż 11) i napisz sobie do niego prawdziwy test jednostkowy.

Jak później rozpatrzysz co się stało to powinno stać się jasne ,że gdybyś miał najpierw poprawny test to nie wytworzyłbyś popsutego kodu. A "cyclomatic complexity" to tylko jedna z wielu metryk które można spie***lić.

pzdr

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Co moją testy do jakości kodu ?
Czy jest jakiekolwiek sensowne przełożenie jakości kodu na poprawność wyników jakie generuje ?

Najlepiej wytłumaczyć to empirycznie.

Proszę o możliwie precyzyjne i możliwie logiczne :)

Najpierw zerknij sobie np. na metrykę http://en.wikipedia.org/wiki/Cyclomatic_complexity.

Napisz kod który będzie miał cyclomatic complexity powiedzmy 30 (gdzie zalecane jest nie więcej niż 11) i napisz sobie do niego prawdziwy test jednostkowy.

Hm.. ok.

1. "Biorę" interfejs tego "zabójczego kodu".
2. Czytam specyfikację funkcjonalności jaką ten kod ma realizować; szukam w niej rozdziału "testy jednostkowe".
3. Dla każdej metody (atomowej funkcjonalności) z interfejsu implementuje testy wymienione w specyfikacji.

... tak przynajmniej, według mnie, powinno być

Jak później rozpatrzysz co się stało to powinno stać się jasne, że gdybyś miał najpierw poprawny test to nie wytworzyłbyś popsutego kodu.

A jak ktoś inny napisze ten test ? Czy też popełnię kod który "robi to coś co warto rozpatrzyć" ?

O co jestem mądrzejszy po samodzielnym napisaniu testów ?

A "cyclomatic complexity" to tylko jedna z wielu metryk które można spie***lić.

Jak metrykę można spie***lić ?
Można popsuć "kilogram" ? :>

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jakub Wojt:

Najpierw zerknij sobie np. na metrykę http://en.wikipedia.org/wiki/Cyclomatic_complexity.

Napisz kod który będzie miał cyclomatic complexity powiedzmy 30 (gdzie zalecane jest nie więcej niż 11) i napisz sobie do niego prawdziwy test jednostkowy.

Hm.. ok.

1. "Biorę" interfejs tego "zabójczego kodu".
2. Czytam specyfikację funkcjonalności jaką ten kod ma realizować; szukam w niej rozdziału "testy jednostkowe".
3. Dla każdej metody (atomowej funkcjonalności) z interfejsu implementuje testy wymienione w specyfikacji.
... tak przynajmniej, według mnie, powinno być

A próbowałeś tak robić z "odziedziczonym" kodem napisanym przez "ruskich hakerów"?

Naprawdę bez złośliwości polecam pozycję :
http://www.amazon.com/Test-Driven-Development-Kent-Bec.... Jak będziesz sobie implementował przykład po przykładzie powinieneś zauważać jakie zyski daje ci podejście TDD.

Książka ma około 200 stron i ja osobiście nie umiem nauki z niej płynącej zawrzeć w jednym poście. Może ktoś inny na forum w tym pomoże. Tymczasem możemy zaryzykować eksperyment myślowy, zobaczymy czy to nie będzie strata czasu.

Załóżmy, że masz przed sobą klasę "UserManager" z metodą "addUser" . W specyfikacji masz napisane, że metoda sprawdza poprawność danych użytkownika łącząc się z zewnętrznym serwisem sprawdzającym pesel, łączy się z baza i tam zapisuje dane użytkownika, na dysk zapisuje jego zdjęcie, a na koniec wysyła email do administratora portalu.
Napisz zestaw testów jednostkowych.

A "cyclomatic complexity" to tylko jedna z wielu metryk które można spie***lić.

Jak metrykę można spie***lić ?
Można popsuć "kilogram" ? :>

Ta, Big makiem. Przyzwyczaj się do skrótów myślowych i napisz mi od razu czy będziemy się łapać za słówka, bo jeśli tak to nie będę tracił czasu na tę dyskusję.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

A próbowałeś tak robić z "odziedziczonym" kodem napisanym przez "ruskich hakerów"?

Hm.. nie :) Uważam, że taki kod jest "nietestowalny". Tzn można napisać dla niego testy które dzielnie sprawdzają 'różne' rzeczy ale IMHO jest to czynność:

1. jeśli w dokumentacji są opisane testy - mało efektywna tzn wiemy, że aplikacja 'przechodzi' testy logiki biznesowej ale nie wiemy czy program ma poprawnie napisana logikę 'niebiznesową'.

2. jeśli w dokumentacji nie ma opisanych testów - nonsensowną.
W takich przypadkach można jedynie testować funkcjonalność 'niebiznesową'. W kontekście tego, że nie wiemy co ma ona de facto robić (nie mamy dokumentacji testów), pisanie i przeprowadzanie takich testów jest absurdalne.

Wiem, że są programiści którym powyższe nie przeszkadza i na zasadzie 'ktoś, kiedyś w jakiejś książce napisał albo ja to tak przynajmniej zrozumiałem' wymyślają dziesiątki testów które właściwie nie wiadomo co testują.

Takie 'wymyślanie' testów w najlepszym przypadku jest stratą czasu -
'poprawianie jakości kodu poprzez implementację testów' - zupełnym nieporozumieniem.

Naprawdę bez złośliwości polecam pozycję :
http://www.amazon.com/Test-Driven-Development-Kent-Bec....
Jak będziesz sobie implementował przykład po przykładzie powinieneś zauważać jakie zyski daje ci podejście TDD.

Hm.. uważam, że testy są nieodłączną częścią projektu tzn są tak samo ważne jak kod który testują.

Załóżmy, że masz przed sobą klasę "UserManager" z metodą "addUser". W specyfikacji masz napisane, że metoda sprawdza poprawność danych użytkownika łącząc się z zewnętrznym serwisem sprawdzającym pesel, łączy się z baza i tam zapisuje dane użytkownika, na dysk zapisuje jego zdjęcie, a na koniec wysyła email do administratora portalu.
Napisz zestaw testów jednostkowych.

To nie jest specyfikacja testów. To nawet nie jest specyfikacja funkcjonalności bo nie ma słowa o tym, co ma się dziać kiedy np. któryś z kroków nie może został wykonany. Czy autor chciał opisać domenę czy to jak została ona zamodelowana w systemie ?

A co powiesz o takim opisie testów:

1.

Parametry przekazywane do metody:

imie - jan
nazwisko - kowalski
PESEL - 9999999
Zdjecie - img.jpg (0.1mb)
Oczekiwany wynik:
metoda rzuca wyjatek "InvalidPESELException"

2.

Parametry przekazywane do metody:

imie - jan
nazwisko - kowalski
PESEL - 82011877453
Zdjecie - img.jpg (0.1mb)

Oczekiwany wynik:
true

3.

Parametry przekazywane do metody (mock bazy danych):

imie - Jan
nazwisko - Kowalski
PESEL - 82011877453
Zdjecie - img.jpg (0.1mb)

Oczekiwany wynik:
metoda rzuca wyjatek "PersistanceContextCreationException" ?

Niczego nie trzeba wymyślać. I ma się tą pewność że autor dokumentacji dobrze wie co robi.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

te trzy przypadki to dokladnie material na trzy testcase, nie wystarczy wpisac to w dokumentacje bo w szerszej perspektywie czasu ona moze sie nie zmieniac natomiast implementacja tak i sensem testowania jest nie tylko sprawdzenei czy aktualny kod dziala ale takze gwarancja ze pozniejsze zmiany w implementacji nie wplyna na poprawnosc dzialania aplikacji

pozatym te przypadki ktore opisales to tylko unittesty ktore sprawdzaja poprawnosc operacji, czasem pisze sie testy ktore sprawdzaja np: ile czasu wykonuje sie dana sekcja kodu przy milionie operacji, albo chociazby testy frontendu w selenium itpŁukasz C. edytował(a) ten post dnia 06.04.11 o godzinie 11:26

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

.Ten post został edytowany przez Autora dnia 04.08.16 o godzinie 20:59

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Łukasz C.:

pozatym te przypadki ktore opisales to tylko unittesty ktore sprawdzaja poprawnosc operacji, czasem pisze sie testy ktore sprawdzaja np: ile czasu wykonuje sie dana sekcja kodu przy milionie operacji, albo chociazby testy frontendu w selenium itpŁukasz C. edytował(a) ten post dnia 06.04.11 o godzinie 11:26

Mała uwaga:
Testy jednostkowe nie sluza do testowania tak jak piłka do metalu nie sluży do
grania w koszykówkę.
Pzdr.

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Piotr T.:

Łukasz C.:

pozatym te przypadki ktore opisales to tylko unittesty ktore sprawdzaja poprawnosc operacji, czasem pisze sie testy ktore sprawdzaja np: ile czasu wykonuje sie dana sekcja kodu przy milionie operacji, albo chociazby testy frontendu w selenium itpŁukasz C. edytował(a) ten post dnia 06.04.11 o godzinie 11:26

Mała uwaga:
Testy jednostkowe nie sluza do testowania tak jak piłka do metalu nie sluży do
grania w koszykówkę.
Pzdr.

"In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. In object-oriented programming a unit is usually a method."

"Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended."

wikipedia ;p

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Parametry przekazywane do metody (mock bazy danych):

imie - jan
nazwisko - kowalski
PESEL - 9999999
Zdjecie - img.jpg (0.1mb)
Oczekiwany wynik:
metoda rzuca wyjatek "InvalidPESELException"

Ok. Bazując na tych trzech punktach napisz w dowolnym pseudokodzie propozycję testów jednostkowych.

Opisze tylko ten. Reszta tworzona jest analogicznie.
Ponieważ jest to pseudo kod - pomijam kwestie użycia takich rzeczy jak NUnit czy mechanizm injection.

bool TestMethod()

{

//persistance

IUserPersistence _usrPrstce = PersistFact.GetInstance('IUserPersistence')

//serivce

IUserService _userService = ServicesFactory.GetInstance('IUserService',   

);



try{

  _userService.RegisterUser('Jan', 'Kowalski', '99999', 'img.jpg');

  return false;

}catch(InvalidPESELException e){

return e.GetType() == typeof(InvalidPESELException);

}



}

Jakub Wojt edytował(a) ten post dnia 07.04.11 o godzinie 11:26

Temat: Czy przy pomocy TDD tworzony kod jest lepszy- eksperyent

Jakub Wojt:

Parametry przekazywane do metody (mock bazy danych):

imie - jan
nazwisko - kowalski
PESEL - 9999999
Zdjecie - img.jpg (0.1mb)
Oczekiwany wynik:
metoda rzuca wyjatek "InvalidPESELException"

Ok. Bazując na tych trzech punktach napisz w dowolnym pseudokodzie propozycję testów jednostkowych.

Opisze tylko ten. Reszta tworzona jest analogicznie.
Ponieważ jest to pseudo kod - pomijam kwestie użycia takich rzeczy jak NUnit czy mechanizm injection.

bool TestMethod()

{

//persistance

IUserPersistence _usrPrstce = PersistFact.GetInstance('IUserPersistence')

//serivce

IUserService _userService = ServicesFactory.GetInstance('IUserService',   

);



try{

  _userService.RegisterUser('Jan', 'Kowalski', '99999', 'img.jpg');

  return false;

}catch(InvalidPESELException e){

return e.GetType() == typeof(InvalidPESELException);

}



}

Jakub Wojt edytował(a) ten post dnia 07.04.11 o godzinie 11:26

No to nie jest test jednostkowy ale akceptacyjny/integracyjny/end-to-end (niepotrzebne skreślić w zależności od używanego słownictwa w środowisku pracy. U mnie tego typu testy nazywamy "end-to-end"). Testy tego typu faktycznie nie wymuszają lepszej jakości kodu.

Wieczorem napiszę jak ja bym do tego podszedł a tymczasem możesz odpowiedzieć na pytanie pomocnicze: jaką "jednostkę" powinniśmy testować w rozpatrywanym teście jednostkowym?

pzdr