Warsztat.GD

Programowanie => Projektowanie kodu => Wątek zaczęty przez: kaban w Marzec 07, 2012, 12:15:39

Tytuł: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: kaban w Marzec 07, 2012, 12:15:39
Witam,

piszemy powoli grę i na mnie przypadło stworzenie całego GUI. Chcę to zrobić porządnie, więc zacząłem od diagramu klas w UML'u. Rozrysowałem sobie to mniej więcej i czy wg was taki diagram jest w porządku?
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: vashpan w Marzec 07, 2012, 12:39:20
Po prostu zaimplementuj to i sprawdz czy bedzie dobrze dzialalo i wystarczalo na twoje potrzeby. Na pierwszy rzut oka - przerost formy nad trescia.

Ogolnie - odpusc sobie takie pierdoly jak UML o ile nie pracujesz w jakiejs korporacji gdzie ty bedziesz robil projekt a kto inny go implementowal... ( albo na odwrot )

Jak bedziecie sie zajmowali takimi glupotami zamiast robic gre, to dalej bedziecie robic ja "wolno" ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: kaban w Marzec 07, 2012, 12:47:12
ogólnie rzecz biorąc ta gra ma być naszą "wizytówką"/podkładką w portfolio w jakiejś firmie i dlatego chciałem to napisać wg sztuki programistycznej :)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: vashpan w Marzec 07, 2012, 12:55:04
ogólnie rzecz biorąc ta gra ma być naszą "wizytówką"/podkładką w portfolio w jakiejś firmie i dlatego chciałem to napisać wg sztuki programistycznej :)

No to napisz kod a potem wygeneruj diagramy z niego... ( true story - tak zaliczalem Inzynierie Oprogramowania :D, 4 weszlo... ) A zaprojektuj go sobie po prostu na kartce papieru z olowkiem na kibelku.

Aczkolwiek - to nie jest "wedlug sztuki programistycznej", nie ma czasu na takie glupoty ( przynajmniej w gamedevie z ktorym sie zetknalem )
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 07, 2012, 13:08:53
Tak na dobrą sprawę sam UML-owy diagram klas za dużo nie mówi dla osoby postronnej. Jak już chcesz się zajmować diagramami to pierwszym powinien być(przynajmniej w moim odczuciu) diagram przypadków użycia. Niestety prawie każdy programista jak myśli o diagramach UML to od razu przed oczami staje mu diagram klas :).

Osobiście nigdy nie używam czystego diagramu klas, dużo lepiej pracuje mi się z diagramem, który skupia się na relacjach między klasami: "kto z kim dlaczego ?" bez planowania jak zmienne i metody będą się nazywać. W swoim diagramie zupełnie to olałeś i pokazałeś samo dziedziczenie i implementowanie interface-ów,  a gdzie chociażby agregacja Window - Widget?
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: kaban w Marzec 08, 2012, 00:15:33
@gotji no racja


chciałem zrobić coś w tym stylu po to, aby za wczasu wszystko przemyśleć, żeby nie musieć później przepisywać kodu
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Kos w Marzec 08, 2012, 12:14:06
Kod zawsze jest czymś, co ewoluuje.

Jeśli chcesz zaprojektować, to pisz na kartce w maksymalnie uproszczonym pseudokodzie, rób sobie luźne schematy, dużo bazgraj, żebyś zobrazował sobie jakie dane którędy przechodzą, jak wygląda control flow, itd.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 08, 2012, 20:55:58
Jeśli chcesz to zrobić porządnie, to zacznij po prostu pisać, ale w TDD.

Narysuj sobie wszystkie byty i wszystkie interakcje, jakie między nimi mają zachodzić. Zmieścisz to na jednej kartce, zgaduję. No, niech będzie, że na dwóch czy trzech. Dostaniesz ogólny obraz sytuacji, który da Ci zbiór wymagań. Następnie weź pierwsze wymaganie z listy, obojętnie jakie, i napisz unit test, który je opisuje. Jeśli nie da się tego zrobić jednym testem, napisz tyle, ile będzie niezbędne. Następnie napisz kod, który zadowoli te testy.

Czynność powtarzaj aż do pełnego sukcesu :)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Avaj w Marzec 09, 2012, 13:58:40
Jeśli chcesz to zrobić porządnie, to zacznij po prostu pisać, ale w TDD.

Narysuj sobie wszystkie byty i wszystkie interakcje, jakie między nimi mają zachodzić. Zmieścisz to na jednej kartce, zgaduję. No, niech będzie, że na dwóch czy trzech. Dostaniesz ogólny obraz sytuacji, który da Ci zbiór wymagań. Następnie weź pierwsze wymaganie z listy, obojętnie jakie, i napisz unit test, który je opisuje. Jeśli nie da się tego zrobić jednym testem, napisz tyle, ile będzie niezbędne. Następnie napisz kod, który zadowoli te testy.

Czynność powtarzaj aż do pełnego sukcesu :)
jak wyglądają unit testy dla GUI?
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: kaban w Marzec 09, 2012, 14:05:11
można np obliczać czy współrzędne się zgadzają, wszystkie obliczenia matematyczne, czy jak np dla okna dam przezroczystość, czy wszystkie kontrolki je będą dziedziczyć i tym podobne
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: hashedone w Marzec 09, 2012, 15:47:24
@Avaj - jak znajdziesz jakimś cudem odpowiedź na to pytanie to daj znać, bo od dwóch tygodni tłumaczę się z braku UT do GUI.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Kos w Marzec 09, 2012, 16:57:41
Głupoty gadacie. Selenium RC! :D (Do web appów.)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Xirdus w Marzec 09, 2012, 19:58:04
można np obliczać czy współrzędne się zgadzają
Jedyne co mi na myśl przychodzi to takie coś:
button.x = 15;
assert (button.x == 15);
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 09, 2012, 22:56:45
jak wyglądają unit testy dla GUI?
Wyobraź sobie rozdzielenie renderera od modelu GUI i testowanie samego modelu zgodnie z jego wymaganiami. Kaban podał przykłady. Ta część jest względnie prosta.

Teraz wyobraź sobie fake'ową implementację biblioteki, której renderer używa do rysowania po ekranie. Zlinkuj z nią program testowy dla testów samego renderera. Ta część jest trudniejsza, ale też się da :)

Cały trik z testowaniem polega na łamaniu zależności. Im mniej zależności w kodzie, tym łatwiej go otestować. Zależności można łamać na poziomie kompilacji albo na poziomie linkowania. To drugie stosuje się w wyjątkowo nieprzystępnych sytuacjach, jak np. integracja z jakimś sterownikiem.

Testy integracyjne nie wymagają łamania zależności, bo testują poszczególne use case'y całego działającego cacka.

Samo łamanie zależności to niezła zabawa jest. Polecam dorwać jakiś legacy kod, na przykład swój własny sprzed kilku lat, i zapitolić mu testy do najbardziej spaghetti-fragmentu, jaki uda się znaleźć ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Avaj w Marzec 09, 2012, 23:18:11
Super, tyle teoria, już widzę jak komuś by się chciało pisać fake'ową implementację biblioteki i jeszcze na maksa rozdzielać widok od modelu i to wszystko testować.

Może w aplikacji biznesowej tak, ale tu jest gamedev i trochę inne zasady ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 10, 2012, 00:07:05
Super, tyle teoria, już widzę jak komuś by się chciało pisać fake'ową implementację biblioteki i jeszcze na maksa rozdzielać widok od modelu i to wszystko testować.

Może w aplikacji biznesowej tak, ale tu jest gamedev i trochę inne zasady ;)
Fejkowa implementacja biblioteki to może być zaledwie kilka funkcji, ni mniej ni więcej, tylko te, z których korzysta akurat testowana jednostka. Mało tego - dla każdego przypadku testowego ta implementacja będzie zapewne różna, bo będzie odzwierciedlała oczekiwaną reakcję na ten właśnie przypadek.

Nie ma znaczenia, jaką aplikację testujesz. Każda aplikacja zawiera jakiś podział. Czy go nazwiesz warstwami czy modułami czy jakkolwiek inaczej - odseparowane części da się testować osobno. Nie ma "innych zasad" w gamedevie. Wszędzie zasady są takie same. To jest wytwarzanie oprogramowania :)

Argument o "nie chceniu" jest wysoce nietrafiony. Przestaniesz go używać, kiedy dostrzeżesz korzyści płynące z TDD :) Jedyne niechcenie jakie tu może wystąpić, to wyraźny zakaz Twojego przełożonego, poparty brakiem wiedzy klienta o korzyściach płynących dla niego z Twojego zaangażowaniu w testowanie. Innych nie znalazłem :)

Jeśli tworzy się soft z głową, to nie może być mowy o ciasnym wiązaniu komponentów, bo to zawsze zabija projekty. Przy odpowiednim ich rozmiarze, rzecz jasna ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: zxc w Marzec 10, 2012, 00:44:58
siso: Już któryś raz słyszę od Ciebie o TTD. Nawet się zainteresowałem, dzięki :).

Możesz podać przykłady gier wyprodukowanych w ten sposób? Po pobieżnym ogląddzie widzę to tak: w przypadku małej gry TTD to strata czasu, w przypadku dużej gry - duża gra to strata czasu, zrób małą. Polecanie TTD startującym developerom to chyba nieporozumienie wobec tego. Jakie masz na to kontrprzykłady. Jakieś success stories?
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 10, 2012, 01:01:14
siso: Już któryś raz słyszę od Ciebie o TTD. Nawet się zainteresowałem, dzięki :).

Możesz podać przykłady gier wyprodukowanych w ten sposób? Po pobieżnym ogląddzie widzę to tak: w przypadku małej gry TTD to strata czasu, w przypadku dużej gry - duża gra to strata czasu, zrób małą. Polecanie TTD startującym developerom to chyba nieporozumienie wobec tego. Jakie masz na to kontrprzykłady. Jakieś success stories?
Nie, nie mogę Ci podać przykładów. Wybacz. Nie pracuję niestety w gamedevie, nie zbieram statystyk z pracy innych, nie powiem Ci z całą pewnością, że takiego  Wieśka 2 robiono w TDD. Podejrzewam nawet, że go tak nie robiono.
Ale to wszystko nie oznacza, że się nie da. Ani że ktoś faktycznie tego nie używa. Nie ma powodu, żeby ludzie nie zwracali się w stronę dobrych narzędzi z czasem.
I nie ma powodu, żeby to negować, zanim się spróbuje.

A success story będzie, i to jeszcze moja własna, kiedy wreszcie zbiorę się w sobie i skończę taki niewielki projekcik, który mi gdzieś tam ciągle wisi i uparcie nie chce dać się zakończyć ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: yarpen w Marzec 10, 2012, 01:09:47
Nie, nie mogę Ci podać przykładów. Wybacz. Nie pracuję niestety w gamedevie, nie zbieram statystyk z pracy innych, nie powiem Ci z całą pewnością, że takiego  Wieśka 2 robiono w TDD. Podejrzewam nawet, że go tak nie robiono.
Nie robiono. Nie znam zadnej gry AAA robionej w ten sposob.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: lmmilewski w Marzec 10, 2012, 08:23:26
@Avaj nie wiem co rozumiesz przez fake'ową implementację biblioteki, ale nie musisz tego robić.

załóżmy, że masz taki kod (uwaga, będzie pseudokod!):
int foo(Biblioteka* b) {
  int q = b->wtf(time(NULL));  // wywołaj wtf z argumentem time(NULL), ...
  return b->foobar(q); // a wynik przekaż do foobar i zwróć to, co zwróci foobar
}

możesz napisać taki test:
Biblioteka* b = mock.CreateMock(Biblioteka); // stwórz mock Biblioteki. (mock to biblioteka do mocków)
 // najpierw "nagrywamy" co powinno się stać
 b->wtf(mock.Ignore()).AndReturn(10); // oczekuj wywołania 'wtf' z dowolnym argumentem. Zwróć 10
 b->foobar(10).AndReturn(42) // oczekuj wywołania foobar z argumentem 10. Zwróć 42

 mock.ReplayAll(); // przejdź w tryb "odtwarzania"
 int r = foo(b); // wstrzyknięcie (dependency injection) mocka zamiast implementacji Biblioteki
 mock.VerifyAll(); // sprawdź czy wszystkie oczekiwane wywołania wystąpiły
 assertEqual(42, r); // spwardź czy wynik się zgadza

To oczywiście jeden ze sposobów testowania, ale ja go lubię - stąd taki przykład.

Jest haczyk - trzeba używać Dependency Injection. Jeżeli zamiast interfejsu użyjesz gdzieś konkretnej klasy to nie wstrzykniesz mocka. W przykładzie powyżej podmienienie time(NULL) np. jest trudne.

Z drugiej strony, jeżeli używasz DI w dużym projekcie to masz problem z inicjalizacją obiektów i zaczynasz wydziwiać z fabrykami itp. Chyba, że użyjesz frameworka do DI.

Jeżeli ktoś chce się bawić to polecam Python + mox na początek. To jest łatwy start w TDD. W Pythonie framework do mocków może wykorzystywać monkey patching, co sporo ułatwia.

W momencie, w którym zaczynasz pisać fake'ową bibliotekę, zaczynasz robić testy integracyjne, a nie jednostkowe, a tu już powiązanie z TDD nie jest aż tak oczywiste.

@siso Nie jest prawdą, że dla każdej aplikacji da się napisać łatwo testy. Pisanie testów do istniejących projektów C++ jest np. trudne. Głównie przez problemy z zależnościami. Powiem więcej - dla mnie pisanie testów do mojego kodu - napisanego kilka minut/godzin wcześniej było trudne. "test first" jest naprawdę jedynym podejściem, jeżeli nie chcesz się zrazić.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Kos w Marzec 10, 2012, 11:00:27
Używałem unit testów w ograniczonym zakresie, do testowania jakchś tam algorytmów / ustrojstw, czy dobrze działają; nie używałem jeszcze TDD, nie mam jeszcze opinii na jego temat.

Dawałem radę używać (na małą skalę) testów bez podejścia "test first" - pisałem kod, stwierdzałem że jest skomplikowany i "niepewny", po czym pisałem do niego testy. Jeśli nie dawałem rady napisać testów, to go strukturyzowałem, by był rozbity na jakiegokolwiek rodzaju mniejsze jednostki (samo to nieraz znalazło mi buga :)) i testowałem je osobno, z powodzeniem. (Przez "z powodzeniem" rozumiem, że moje buraki wyszły w testach, a nie po wdrożeniu.)

Wyciągam stąd wniosek, że testy są bardzo fajne, ale TDD to niekoniecznie jedyna słuszna droga.

możesz napisać taki test:

Takie testy generalnie nic mi nie mówią. Widzę często takie pseudokodowe przykłady pisane przez entuzjastów, ale to jest straszne uproszczenie i myślę, że nie jestem jedynym "zielonym", któremu to niewiele mówi... :)

Myślę, że trzeba po prostu spróbować, by to polubić.

No dobra, jestem w stanie wyobrazić sobie, że mam jakąś klasę, która w reakcji na coś robi coś skomplikowanego, i akurat z góry wiem, że w konkretnym przypadku jej rezultat to ma być takie i takie wywołanie do obiektu XYZ. Wtedy mock mi pomoże napisać test.

Moje testy jednak zwykle wyglądały tak: Mam dane takie i takie, odpalam na nich algorytm i sprawdzam, czy po algorytmie dane zmieniły się w ten i ten sposób. Albo że nie zmieniły się wcale.
W takiej sytuacji mocki niewiele mi dadzą, bo nie wiem, jakie operacje mają być rezultatem akcji, wiem natomiast, jakie są oczekiwane dane.



Jeszcze trochę przeciwko TDD: Kod jestem w stanie przetestować lepiej, gdy go już napiszę. Jeśli zagadnienie uda mi się zaprogramować, to zapewne gdzieś po drodze udało mi się je zrozumieć :), zrobić sobie w głowie lub na kartce jakiś logiczny model, zidentyfikować różne dziwne edge cases bądź niespodziewane zawiłości. Jeśli mam kod, to znaczy, że zastanowiłem się i podjąłem decyzję, jak algo ma się zachowywać w tych zawiłościach.
Mogłem ofc się gdzieś pomylić, więc piszę testy. Ale teraz znam już konkretne zawiłości problemu (niekoniecznie zawiłości implementacji, ale właśnie samego problemu!) które muszę szczególnie przetestować. Nie znałem tych zawiłości przed stworzeniem kodu do testowania, więc testując później otrzymuję dokładniejsze testy.

Z tego powodu nie spieszę się z wypróbowaniem TDD.

Powyższego bardzo proszę nie mylić z "code tests against interface, not implementation" - to akurat znam i popieram :)



Mam natomiast nawyk pisania "pseudotestów" pseudokodem przed implementacją, bo to mi bardzo ułatwia wyobrażenie sobie, jak wygodnie lub niewygodnie się będzie z kodu korzystało.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Avaj w Marzec 10, 2012, 12:20:55
@Avaj nie wiem co rozumiesz przez fake'ową implementację biblioteki, ale nie musisz tego robić.
siso wyjechał z "fake'ową implementacją biblioteki" :)

Jak dla mnie TDD to zwykły topdown design, tylko się tak ładnie nazywa i go tak zenterprise'owano
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Kos w Marzec 10, 2012, 12:42:07
Topdown design to ogólne pojęcie, a TDD to bardzo, bardzo szczególne podejście do kodowania (i to nie tylko designu).
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 10, 2012, 12:44:07
Nie można traktować UT jako lekarstwo na całe zło, testy mają swoje wady i trzeba wiedzieć co testować i jak testować. Złe testy są o wiele gorsze niż ich brak. W necie kiedyś natknąłem się na ciekawy artykuł, który nazywał złe testowanie okradaniem swojego pracodawcy i ciężko było się z nim nie zgodzić. Gry ciężko się testuje bo często tak samo ważne jak rezultat jakiegoś bloku kodu ważna jest wydajność, którą ciężko jest zmierzyć 'z zewnątrz' aplikacji. Sporo kodu bazuje na 'asset'-ach, których nie da się w prosty sposób zasymulować. Testy to ogromny nakład pracy i nie ma tu na myśli ich pierwszego pisania tylko ich utrzymywania. Kod z czasem ewoluuje, a z nim muszą ewoluować testy.

Nie jestem przeciwnikiem testowania, sam używam BDD w pracy od przeszło dwóch lat, ale jak po godzinach koduje małe gry to się wystrzegam takich praktyk:)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 10, 2012, 14:06:17
Uhm, czyżbym napisał gdzieś, że testy zawsze pisze się łatwo? :) Otóż nie. Nie zawsze jest łatwo. Ale zawsze można kod doprowadzić do takiej formy, że się da.

Widzę, ze jest spora obrona :) To naturalne. Ja też się broniłem. Dopóki dwóch sprytnych gości na szkoleniu nie pokazało mi jak faktycznie należy podchodzić do testowania.

Najważniejsze jest zawsze pytanie Co testować?. Nie jest prawdą, że wszystko. Nie należy pisać testów do rzeczy trywialnych lub takich, których koszt jest niższy niż przygotowanie środowiska do testów. Inna kwestia, że akurat zawsze da się takie środowisko przygotować. Ale czasami można przyjąć, że "nie ma czasu/nie ma pieniędzy".

@Kos
Testowanie z użyciem mocków jest potrzebne wtedy, kiedy musisz zbadać flow. Jeśli wystarczy tylko zadać jakieś wejście i sprawdzić wyjście, jest ok. Idealna sprawa przy algorytmach.
Jeśli masz nawyk pisania pseudokodu, może zechciałbyś spróbować zamiast pseudokodu napisać po prostu test? Test bez implementacji jest przecież pseudokodem :) I zawsze pokaże Ci on, jak się czegoś używa. Przy okazji też uwolni Cię od myślenia o zależnościach.

Mówisz, że piszesz test po implementacji, bo znasz już zasadę działania i wiesz co testować. Dlaczego znasz zasadę działania dopiero teraz? Od czego zacząłeś implementację? W ciemno? :) Zanim zaczniesz, wiesz w największym zarysie co ma się stać. Napisz test, który to sprawdzi. Masz już test, piszesz kod, jest zielono. Napisz następny test, dla następnego wymagania. I nagle ZONK! Odkryłeś kolejne wymaganie, które nie istniało dla Ciebie przed poznaniem zasady działania. Nie ma sprawy, napisz szybko test, który je opisuje i wróć do przerwanej pracy. Kiedy skończyłeś z poprzednim, zaimplementuj to nowe, dopiero odkryte wymaganie.
Refaktoryzuj kod i testy. Jeśli okaże się, że test był zły, zmień go.

@Avaj
Nie wyjechałem z fejkową biblioteką, tylok podsunąłem ten pattern jako jedno z możliwych rozwiązań trudnych, z pozoru nierozwiązywalnych sytuacji.



Testowanie jednostkowe wymaga diametralnej zmiany podejścia do programowania. Zwłaszcza TDD, gdzie nie myśli się o kodzie, a o wymaganiach, testach do nich i dopiero kodzie, jako skutku ubocznym. No, prawie ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 10, 2012, 21:06:33
Uhm, czyżbym napisał gdzieś, że testy zawsze pisze się łatwo? :) Otóż nie. Nie zawsze jest łatwo. Ale zawsze można kod doprowadzić do takiej formy, że się da.
 

Chodzi o to, że czasami nie warto stawać na głowie po to żeby kod doprowadzać do takiej formy, bo może to powodować inne problemy chociażby wydajnościowe. Nie wspominając już o wzroście kosztu, który z założenia TDD ma się zmniejszyć.

Widzę, ze jest spora obrona :) To naturalne. Ja też się broniłem. Dopóki dwóch sprytnych gości na szkoleniu nie pokazało mi jak faktycznie należy podchodzić do testowania.
 

Też się bronisz. Spróbuj dostrzec negatywne strony TDD, nic nie jest złotym środkiem.

Najważniejsze jest zawsze pytanie Co testować?. Nie jest prawdą, że wszystko. Nie należy pisać testów do rzeczy trywialnych lub takich, których koszt jest niższy niż przygotowanie środowiska do testów. Inna kwestia, że akurat zawsze da się takie środowisko przygotować. Ale czasami można przyjąć, że "nie ma czasu/nie ma pieniędzy".
 

Tak jak mówisz nie wszystko trzeba testować. Tylko wyobraź sobie jakiś większy moduł \ warstwę 'pokrytą' testami jak sito? Co takie testy dadzą? że po wprowadzeniu w przyszłości zmian będziesz miał pewność, że 30% twojego modułu nadal działa, a co z resztą? Są projekty, które ładnie da się pokryć testami prawie w 100%, ale są też takie, które będą wyglądać jak sito i z moich obserwacji(amatorskiego programisty gier) projekty gamedev-owe zaliczają się do drugiej grupy i podejście 'test first' jest nieopłacalne. Może ktoś zajmujący się profesjonalnie gamedev-em ma inne doświadczenia.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: rm-f w Marzec 10, 2012, 21:30:30
Zaprezentuj nam po prostu na jakimś przykładzie, kawału z gry.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 10, 2012, 22:02:30
Kilka postów wcześniej napisałem, że dręczy nie pewien mały projekcik po godzinach. Jak tylko ujrzy światło dzienne, zaprezentuję.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: rm-f w Marzec 10, 2012, 22:13:58
Jak tylko ujrzy światło dzienne, zaprezentuję.
Wymigujesz się. :| Jeden przykład z życia.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 10, 2012, 22:18:42
Wymigujesz się. :| Jeden przykład z życia.
Skąd Ci wezmę? Muszę napisać, tak? :) To co zrobiłem do tej pory było jeszcze zanim poznałem TDD, więc się nadaje do refactoringu raczej.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: rm-f w Marzec 10, 2012, 22:38:09
Skąd Ci wezmę? Muszę napisać, tak? :)
Tak.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: lmmilewski w Marzec 11, 2012, 04:44:42
Cytuj
Takie testy generalnie nic mi nie mówią. Widzę często takie pseudokodowe przykłady pisane przez entuzjastów, ale to jest straszne uproszczenie i myślę, że nie jestem jedynym "zielonym", któremu to niewiele mówi... :)

Pewnie masz rację, że pseudokod to za mało. Jaki przykład/projekt wg Ciebie byłby wystarczający, żeby pokazać jak pisać testy, żeby to nie było bolesne (dla tych, którzy są przekonani, że chcą to robić, ale nie wiedzą jak)?

Dla jasności - ja nie będę nikogo przekonywał. Szczególnie, że sam nie jestem "entuzjastą". Czasami wykorzystuję TDD i jak narazie w tych przypadkach się sprawdzało (czyt. zaoszczędziłem czas).
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Xender w Marzec 11, 2012, 08:52:05
Widzę, ze jest spora obrona :) To naturalne. Ja też się broniłem. Dopóki dwóch sprytnych gości na szkoleniu nie pokazało mi jak faktycznie należy podchodzić do testowania.
Może więc przekaż nam tą wiedzę, żebyśmy mogli się przekonać?
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Kos w Marzec 11, 2012, 11:10:51
@up Siso nie przekazał, bo potrzebuje jeszcze drugiego sprytnego gościa do kompletu. :)

Wiesz, Extreme Teaching, zawsze w parach.

@lmmilewski:
Cytuj
Jaki przykład/projekt wg Ciebie byłby wystarczający, żeby pokazać jak pisać testy, żeby to nie było bolesne (dla tych, którzy są przekonani, że chcą to robić, ale nie wiedzą jak)?

Uch, jakikolwiek, który sam napiszę i mi się spodoba :).
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 11, 2012, 15:15:03
Może więc przekaż nam tą wiedzę, żebyśmy mogli się przekonać?
Mam wrażenie, że robię to o d swojego pierwszego postu o TDD ;)

@up Siso nie przekazał, bo potrzebuje jeszcze drugiego sprytnego gościa do kompletu. :)

Wiesz, Extreme Teaching, zawsze w parach.
LOL, to dobre :)
Swoją drogą w parach jest łatwiej tededować.

Wytededuję jakiś kawałek prostego gameplaya (niestety, w pojedynkę) jak tylko ogarnę się z bieżącą robótką.
Peace! ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: dikamilo w Marzec 11, 2012, 20:20:41
Cytuj
jak wyglądają unit testy dla GUI?
Testy wyglądają tak samo :) Chodzi o to żeby testować zachowanie obiektów. Weźmy na przykład przycisk w UI, co on ma robić ? Jeżeli użytkownik kliknie w obszarze gdzie znajduje się ten przycisk to ma się wywołać callback na funkcję obsługi tego przycisku - więc napiszmy test.

Pseudo kod, składnia typowa dla google test i google mock:
TEST(ButtonTest, callListenerOnClick) {
  ClickListenerMock listener;
  Button button;
  button.register(&listener);

  // oczekuje że metoda onClick zostanie wywołana raz
  EXPECT_CALL(listener, onClick()).Times(1);

  button.onMouseClick(10, 20);
}
Robię tutaj mock na listenera aby było prościej - równie dobrze mogę dziedziczyć po klasie listenera i w metodzie onClick ustawić jakieś pole bool na true a potem sprawdzać ASSERT_TRUE(true, listener.clicked); - mockiem jest dużo prościej w tym wypadku.

Jak zaimplementować kod aby test przeszedł ? Dodać listenera jako pole prywatne, zaimplementować metodę register, zaimplementować onMouseClick NAJPROŚCIEJ JAK SIĘ DA - czyli wywołujesz listener.onClick za każdym razem. Potem piszesz drugi test w którym oczekujesz że onClick się nie wywoła jeżeli kliknięcie jest po za przyciskiem. I tak dalej i tak dalej... Ogólnie chodzi o to aby robić małe kroczki.

Inny przykłady ? Ustawiam na przycisku teksturę i oczekuję że wyświetli się z teksturą (odpowednie funkcje renderera zostaną wywołane w metodzie render itp.).

Nie jestem żadnym specjalistą, sam próbuje używać TDD w swoich projektach - ostatnio piszę mały framework do gier 2D tą techniką, za dużo jeszcze nie ma więc nie podam jakiś większych przykładów itp.

Prosty przykład klasy zajmującej się obliczaniem delty (metody tej klasy wywoływane są w głównej pętli):

Klasa sama w sobie: http://pastebin.com/vqmQd1JP
Testy jednostkowe: http://pastebin.com/nPsEvrHq
Mock: http://pastebin.com/8Vv6sxbX

W C++ problem jest taki że sporo bibliotek, API np. openGL to są funkcje globalne których testowanie jest trudne a czasami nie możliwe. I teraz aby testować aplikację która używa np. opengl musimy zapakować wszystkie te funkcje do jednej klasy - interfejsu i używać dependency injection w naszych klasach. Chyba że napiszemy renderer którego nie będziemy testować a w testach będziemy używać mock.

TDD vs gamedev ?
http://gamesfromwithin.com/category/test-driven-development
szczególnie 3 cześć "Stepping Through the Looking Glass: Test-Driven Game Development"
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Xender w Marzec 11, 2012, 23:27:50
Klasa do liczenia dt? No bez jaj, ile masz tych pętli głównych że musiałeś wyodrębnić to do osobnej klasy? Rozumiem wrapper na timer ale to jest... dziwne...

Poza tym to zły przykład. Na tak prostym kodzie widać od razu czy działa dobrze czy nie - zalicza się do tych przypadków niewymagających testów. Można prosić o jakiś sensowny przykład?
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 12, 2012, 10:03:52
@dikamilo To co pokazałeś jest prawdziwe i wszystko ładnie pięknie tylko że kod który pokazujesz jest 'powszechny', który równie dobrze może pochodzić ze zwykłej aplikacji okienkowej np. WinFormsy. Problemy się pojawiają kiedy dotykasz trochę niższego poziomu jak assety i praca na nich, małe optymalizacje itp.. Pokrycie takich rzeczy testami jest możliwe, ale zmusza to programistę do trzymania kodu jako 'obiektową kobyłę', która jest bardzo kosztowna w utrzymaniu. Z doświadczenia wiem, że główny koszt testu to nie jego napisanie lecz jego utrzymanie.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 12, 2012, 17:15:12
@gotji
Pokaż, jeśli możesz, taki problematyczny kawałek pracujący blisko assetów. Być może uda nam się coś wspólnie rozkminić.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 12, 2012, 19:52:43
Swego czasu zaczełem nowy projekt w XNA i założenie było takie, że lecę całość podejściem DDD + BDD. Pomyślałem, że koro w pracy się tak super sprawdza to czemu tu ma być inaczej. Frustracja pojawiła się przy implementacji ContentProcessor-a, Importer-a, Writer-a i Reader-a. Pierwsze podejścia to masa wrapper-ów, dzięki którym zamiast czystego kodu miałem 'obiektową papkę'. Koniec końców wywaliłem wszystko bo po prostu tego nie dało się sensownie przetestować.

Po jakimś czasie trafiła do mnie informacja, że używanie event-ów jest mocno niewskazane z uwagi na to że generują masę śmieci i GC na Xboxie sobie z tym nie radzi(radzi ale spadek wydajności jest przerażający). Są na to obejścia ale dosyć uciążliwe. W tym momencie zostałem pozbawiony wspaniałego narzędzia do decoupling-u. Efekt: rzeźbienie kodu. Miałem masę kodu po to tylko żebym mógł używać BDD. Każda zmiana w kodzie skutkowała poprawianiem testów. Doszedłem do wniosku, że nie ma sensu testować na siłę części aplikacji skro 'środowisko', w którym pracuje, tak mocno się przed tym broni. No to wtedy zaczęło się testowani tylko niektórych elementów. Skutek taki, że miałem kod pokryty testami na oko w 30-50%.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 13, 2012, 11:31:32
Fakt, kiedy testy się rozjadą, trudno nad nimi ponownie zapanować. Z samego opisu wynika, że model obiektowy może być nie najlepszy do tego, co chciałeś osiągnąć. Albo niechcący za bardzo go rozdmuchałeś. Dodatkowo rozwijałeś go z dala od testów. Skutek - bałagan w testach i idący za tym ich ciężar.

Mały hint: nie musiało tak być. Unit testy można także pisać do nieobiektowego kodu ;)

Ponowię prośbę o pokazanie jakiegoś fragmentu, o ile oczywiście możesz.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 13, 2012, 12:02:47
Ponowię prośbę o pokazanie jakiegoś fragmentu, o ile oczywiście możesz.

Sprawdź w necie dowolną pełną implementację rozszerzeń do XNA Content Pipline(importer, processor, writer, reader) zobaczysz jak to wygląda, nie będą wklejał paruset linii kodu.

Dodatkowo rozwijałeś go z dala od testów.

Skąd ten wniosek? Było wprost przeciwnie. DDD + BDD to bardzo dobre uzupełniające się połączenie.

Mały hint: nie musiało tak być. Unit testy można także pisać do nieobiektowego kodu ;)

Bez modelu obiektowego ciężko jest uzyskać 'decoupling' na sensownym poziomie, żeby możliwe było TDD(i pochodne wersje). TDD wymaga tego aby projekt miał odpowiednią formę inaczej użycie jest praktycznie niemożliwe bądź jest męką. Nie piszemy tu o samych UT tylko o podejściu TDD.

Celem mojej wypowiedzi jest podzielenie się doświadczeniem na temat TDD + amatorski gamedev. W żadnym wypadku nie mówię: "niech nikt tak nie robi!". Z twoich wypowiedzi wynika, że nie pisałeś takiego projektu, a mimo wszystko próbujesz mi wmówić, że robiłem błędy projektowe.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 13, 2012, 13:12:11
Nie, nie próbuję Ci wmówić, że robiłeś błędy projektowe. Nie mogę, bo nie widziałem tego kodu. Ale co do jednego powinniśmy mieć tu jasność: TDD to, jak sama nazwa wskazuje, development sterowany testami. Jeśli możesz napisać do czegoś unit test, to znaczy, że możesz tam praktykować TDD. OOP nie jest jedynym słusznym narzędziem. Ale nie jest też prawdą, że bez OOP nie da się uzyskać SoC, SRP, sensownego podziału na warstwy, jeśli trzeba, czy nawet i polimorfizmu.

Nie trzeba jednak obiektowo pisać, żeby testować jednostkowo. Wiem, bo robiłem tak w C/C++. Tylko trzeba dążyć do jak najmniejszej (zdroworozsądkowo) liczby zależności. Czyli wszechobecne globale zdecydowanie nie pasują - ot, taki przykład :) Kod musi się dać dzielić na w miarę niezależne jednostki. Jeśli tak jest, można tededować :)

Inna sprawa, że ten Content Pipeline wygląda biednie pod względem testfriendlności, ale to już rozmowa na jakieś dłuższe piwo chyba ;)
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: gotji w Marzec 13, 2012, 13:33:39
Jeśli możesz napisać do czegoś unit test, to znaczy, że możesz tam praktykować TDD.

Właśnie tutaj tkwi chyba różnica naszych poglądów. Dla mnie TDD(i pochodne) to pokrycie konkretnej integralnej części kodu praktycznie w 100% testami. Postrzegam to jako sposób na projektowanie i jednoczesne implementowanie pomniejszych elementów modułu \ warstwy. Jeżeli część modułu \ warstwy nie może zostać przetestowana(nie można dla niej napisać testów) to podejściem TDD ten moduł nie może powstać. Dlatego stosuje się różnego rodzaju framework-i oraz wzorce aby 100% testowalność otrzymać i praktycznie każdy projekt pisany podejściem TDD ma narzut z tym związany.

Nie mówię żeby w ogóle nie pisać UT bo  UT powinno się pisać, ale UT z podejściem 'test first' to nie jest równoznaczne z TDD.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: siso w Marzec 13, 2012, 15:12:14
Jeśli jest różnica poglądów, warto ją wyprostować :)

TDD ma bardzo dobrze zdefiniowany cykl pracy: test -> implementacja -> refactoring. Odstępstwa od tego powodują, że już nie pracujesz w TDD. Kluczem jest tu driven, bo to testy mają sterować kształtem kodu, a nie kod kształtem testów.

To pierwsza sprawa. Druga to pokrycie kodu. Nieprawdą jest, że jest wymagane 100%. Nie musisz pokrywać całego kodu, wystarczy że pokryjesz całe API jednostki, czyli  jej publiczny interfejs. Nikt nie wymaga, byś pisał testy dla niepublicznych części. Zresztą, jeśli coś nie jest publiczne, nie bardzo jest jak do tego się dobrać. Lub nie powinno być łatwo, przynajmniej. I nie należy pisać testów do jakichś trywializmów, jak np. akcesory (pytanie wręcz  czy akcesory są zawsze potrzebne?).
Za to stuprocentowo powinny być pokryte wymagania. Może się zdarzyć tak, że jedna metoda (implementacja jakiegoś algorytmu) ma kilka warunków brzegowych. Wtedy możesz mieć do niej i 20 testów, a do pozostałych metod w klasie/module/czymkolwiek po jednej. I będzie dobrze.

Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: rm-f w Marzec 13, 2012, 15:26:08
Bla bla bla bla
(http://bi.gazeta.pl/im/6/9772/z9772216X,LulzSec.jpg)
A mówiłem, dajcie przykład z życia, to nie.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: hashedone w Marzec 13, 2012, 15:46:40
Ja w ogóle nie rozumiem tu podejścia "obrońców" TDD. Osobiście uważam że TDD jest zaje... bardzo dobrym sposobem pisania aplikacji. Sam stosuję i w pracy i we własnych aplikacjach. Ale pisanie w metodologii TDD gry to jak pisanie GUI. Gra to nie silnik. Gra to nie assety. Gra to nie algorytmy, fizyka, czy inne ustrojstwo. 80% testowalnego kodu w grach to middleware które jest obtestowane lub nie, ale programisty który takiego mw używa jest to nie istotne - ma działać, jak nie działa to być może znalazłem bug więc go publikuję twórcą, a oni napiszą test, poprawią i puszczą test, lub po prostu poprawią i przetestują w jakiś inny sposób. Gra zaś to imho przede wszystkim powiązania między wszystkimi jej komponentami. A jeśli mówimy o powiązaniach to już nie mówimy o UT. W najlepszym przypadku mówimy o MT, ale tak na prawdę MT to testy które testują integralne grupy obiektów, nie zależności między niezaleznymi modułami. Gry można by testować na poziomie integracyjnym, ale ludzie - w przypadku gier samo zdefiniowanie takich testów trwało by tyle co pisanie samej gry (tak się testuje GUI, czy narzędzia, gdzie ilość usecasów jest stosunkowo mała, nie grę, gdzie usecasów właściwie nie da się wszystkich rozpisać - rozpisuje się co najwyżej uogólnienia). W grze ważniejsze od automatycznego testowania jest testowanie grywalności, ale tego już automat nie zrobi. Do tego potrzebny tester z możliwością szybkiej zmiany jakiś parametrów rozgrywki.
Co do gier Indie w których faktycznie piszę się natywnie w jakimś OGLu, fizykę się implementuje samemu, a jako input łapie komunikaty WinAPI - jak ktoś już powiedział, do małych gier UT to strata czasu.
Tytuł: Odp: Pisanie GUI oraz projekt ich klas w UML
Wiadomość wysłana przez: Kos w Marzec 14, 2012, 11:22:57
Bez modelu obiektowego ciężko jest uzyskać 'decoupling' na sensownym poziomie, żeby możliwe było TDD(i pochodne wersje).

Nie zgadzam się; zdecydowanie można mieć decoupling bez OO lub OO bez decouplingu :).