Autor Wątek: Wybór silnika  (Przeczytany 16010 razy)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 29, 2007, 17:21:52
Dopiero teraz przeczytałem powyższy post ;)

Cytuj
Ja chciałbym by takie testy umożliwiłyby mi pomieszanie w bebechach klasy, bez konieczności pisania mechanizmów abstrakcyjnych opakowujących mi to - bo po co to w kodzie produkcyjnym?
Unit-testy nie mają w niczym mieszać - mają tylko sprawdzić, czy wszystko jest ok. U mnie to wygląda po prostu tak, że mam osobny projekcik, w którym są unit-testy. W ogóle jest to niezwiązane z kodem aplikacji. I sobie mogę po testować każdą konfigurację, co ma swoje zalety :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline mINA87

  • Użytkownik

# Sierpień 30, 2007, 10:31:49
Dopiero teraz przeczytałem powyższy post ;)

Cytuj
Ja chciałbym by takie testy umożliwiłyby mi pomieszanie w bebechach klasy, bez konieczności pisania mechanizmów abstrakcyjnych opakowujących mi to - bo po co to w kodzie produkcyjnym?
Unit-testy nie mają w niczym mieszać - mają tylko sprawdzić, czy wszystko jest ok. U mnie to wygląda po prostu tak, że mam osobny projekcik, w którym są unit-testy. W ogóle jest to niezwiązane z kodem aplikacji. I sobie mogę po testować każdą konfigurację, co ma swoje zalety :)

Tak ale ja sobie wyobrażam to tak, że jeśli np. pewna metoda przyjmuje określone parametry i modyfikuje wewnętrzny stan klasy, to fajnie by było zrobić unit testy tego. Teraz załóżmy, że nigdzie niepotrzebna jest nam refleksja tych stanów wewnętrznych które chcemy potestować. To co? Piszemy na chama akcesory? Ja w tym miejscu użyłbym lekko nieetycznych rozwiązań by dostać się do składowych klasy ręcznie i posprawdzać ich wartości :)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 30, 2007, 11:53:33
Zwykle stosuje się właśnie takie nieetyczne rozwiązania ;) Czyli najprostsze: deklaracja przyjaźni z klasą zbioru testów/z klasą testu lub wszystkie składowe jako public (choć to lekka masakra jest już ;) ). Bo oczywiście czasem przydaje się dobrać do stanu klasy.

Offline mINA87

  • Użytkownik

# Sierpień 30, 2007, 12:11:26
O widzisz - tyle że ja nie chcę dosłownie NIC modyfikować w deklaracji klasy. Ani zmieniać trybu dostępu, ani zaprzyjaźniać - chcę mieć mechanizm który mi zapewni refleksję modelu obiektu z możliwością niskopoziomowego operowania nim :)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 30, 2007, 12:22:19
No przyznaję jest to problem z unit-testami (i z innymi zresztą też ;) ). Choć na razie nie spotkałem się chyba z obejściem tego problemu w elegancki sposób (przynajmniej nie pamiętam takiego kodu) - po prostu za dużo zachodu ;)
Teoretycznie stan klasy możesz też sobie kontrolować za pomocą wyjątków. Ale rozwiązanie to nadaje się tylko do testów, które podają na wejściu nietypowe/błędne dane (np. próba alokacji zbyt dużego bloku pamięci). Rzucenie wyjątku jest wtedy warunkiem zaliczenia testu.

Offline mINA87

  • Użytkownik

# Sierpień 30, 2007, 12:31:53
W elegancki się nie da. Ja chcę pójść w coś w rodzaju scripting systemu - w skryptach robimy ekspozycję metod i właściwości klasy, ale przeważnie robi się to ręcznie. Nie jest to eleganckie.
Ja chcę wykorzystać wiedzę o modelu obiektu, który generuje konkretny kompilator, przeparsować pliki nagłówkowe i/lub pdb(to mi da jeszcze większe pole do popisu) i na tej podstawie automatycznie odbudować sobie co mi jest potrzebne :) Też nie jest to zbyt elegancki, bo wiele osób będzie to uważało za hackerkę, ale dla mnie perspektywa tego, że w konsoli podczas gry normalnie wywołuję sobie dowolne metody klas silnika jest bardzo kusząca, a przy okazji możnaby zrobić naprawdę potężne narzędzie do unit testingu.

Offline Kurak

  • Użytkownik

# Sierpień 30, 2007, 12:34:30
Może by tak wydzielić posty o unit testach do osobnego wątku, którego tytuł wskazywał by na treść? Bo na razie "Wybór silnika" jest trochę mylący :)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 30, 2007, 12:39:24
Cytuj
Też nie jest to zbyt elegancki, bo wiele osób będzie to uważało za hackerkę, ale dla mnie perspektywa tego, że w konsoli podczas gry normalnie wywołuję sobie dowolne metody klas silnika jest bardzo kusząca, a przy okazji możnaby zrobić naprawdę potężne narzędzie do unit testingu.
Niby tak, ale właśnie dla mnie jest już to nieco przekombinowane rozwiązanie ;) Mi akurat nie zależy w tym przypadku na tak wielkiej kontroli - chcę jedynie by mój kod był możliwie wysokiej jakości, i możliwie mało zabugowany. Choć jak coś takiego stworzysz daj znać, chętnie przetestuję ;)

Cytuj
Może by tak wydzielić posty o unit testach do osobnego wątku, którego tytuł wskazywał by na treść
To prawie cały topic trzeba wydzielić ;)

Offline Kurak

  • Użytkownik

# Sierpień 30, 2007, 12:44:08
Cytuj
Też nie jest to zbyt elegancki, bo wiele osób będzie to uważało za hackerkę, ale dla mnie perspektywa tego, że w konsoli podczas gry normalnie wywołuję sobie dowolne metody klas silnika jest bardzo kusząca, a przy okazji możnaby zrobić naprawdę potężne narzędzie do unit testingu.
Niby tak, ale właśnie dla mnie jest już to nieco przekombinowane rozwiązanie ;) Mi akurat nie zależy w tym przypadku na tak wielkiej kontroli - chcę jedynie by mój kod był możliwie wysokiej jakości, i możliwie mało zabugowany. Choć jak coś takiego stworzysz daj znać, chętnie przetestuję ;)
Riddlemaster, podobno jakiś artykuł chciałeś pisać na temat unittestów, prawda? ;)

Cytuj
Cytuj
Może by tak wydzielić posty o unit testach do osobnego wątku, którego tytuł wskazywał by na treść
To prawie cały topic trzeba wydzielić ;)
Zawsze można pokasować posty dotyczące wyboru silnika i zmienić nazwę tematu ;)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 30, 2007, 12:49:45
Cytuj
Riddlemaster, podobno jakiś artykuł chciałeś pisać na temat unittestów, prawda?
Tak - piszę ;) . Choć przedstawić to w jasny sposób (były prośby, żeby początkujący też mogli zrozumieć), a jednocześnie pokazać coś bardziej zaawansowanego jest dość trudne.

Offline mINA87

  • Użytkownik

# Sierpień 30, 2007, 12:50:49
Cytuj
Też nie jest to zbyt elegancki, bo wiele osób będzie to uważało za hackerkę, ale dla mnie perspektywa tego, że w konsoli podczas gry normalnie wywołuję sobie dowolne metody klas silnika jest bardzo kusząca, a przy okazji możnaby zrobić naprawdę potężne narzędzie do unit testingu.
Niby tak, ale właśnie dla mnie jest już to nieco przekombinowane rozwiązanie ;) Mi akurat nie zależy w tym przypadku na tak wielkiej kontroli - chcę jedynie by mój kod był możliwie wysokiej jakości, i możliwie mało zabugowany. Choć jak coś takiego stworzysz daj znać, chętnie przetestuję ;)

Generalnie mam już jakieś tam pojęcie na temat tego jak zachowuje się kompilator, jak to wszystko wygląda pod maską, jak się dobrać do informacji z pliku pdb, coś tam powoli projektuję, nie mam niestety czasu wziąć się za to na pełnych obrotach i skończyć tego. Mam jednak nadzieję, że pozamykam te bezsensowne zleconka z PHPem i napiszę to w końcu - wtedy na pewno się pochwalę i będziecie mogli liczyć że dam znać jak to wygląda - będzie się można pobawić, a nuż coś ciekawego z tego wyjdzie :)

.

  • Gość
# Sierpień 30, 2007, 13:58:48
Tak ale ja sobie wyobrażam to tak, że jeśli np. pewna metoda przyjmuje określone parametry i modyfikuje wewnętrzny stan klasy, to fajnie by było zrobić unit testy tego. Teraz załóżmy, że nigdzie niepotrzebna jest nam refleksja tych stanów wewnętrznych które chcemy potestować. To co? Piszemy na chama akcesory? Ja w tym miejscu użyłbym lekko nieetycznych rozwiązań by dostać się do składowych klasy ręcznie i posprawdzać ich wartości :)
Ja mam metodę protected virtual Debug w każdej klasie i publiczny bool debug. Jeśli ‘debug == true’, to metoda Debug jest włączana do potoku i na ekranie na bieżąco wyświetlają mi się wszelkie informacje o obiektach, począwszy od macierzy i kontenerów obiektów 3D a skończywszy na widgetach. Kiedy zechcę mogę kliknąć wybraną zmienną i ją zmienić. Jest to na stałe wbudowane w silnik i we wszelkie gry na nim pisane.

Przykład opisanej kontroli[413KB]:


Pomysł prosty i bardzo łatwo znajduje się w nim ewentualne błędy.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 30, 2007, 14:01:18
Tak, ale nie można tu mówić o jakiejkolwiek automatyzacji, a zatem o unit-testach także. Podobny system miałem w poprzednim silniku - teraz niemal całkowicie porzuciłem ten pomysł. Znajdywanie błędu w ten sposób jest IMO trudniejsze niż debugowanie - ale co kto lubi ;) .

Offline mINA87

  • Użytkownik

# Sierpień 30, 2007, 15:02:35
Tak ale ja sobie wyobrażam to tak, że jeśli np. pewna metoda przyjmuje określone parametry i modyfikuje wewnętrzny stan klasy, to fajnie by było zrobić unit testy tego. Teraz załóżmy, że nigdzie niepotrzebna jest nam refleksja tych stanów wewnętrznych które chcemy potestować. To co? Piszemy na chama akcesory? Ja w tym miejscu użyłbym lekko nieetycznych rozwiązań by dostać się do składowych klasy ręcznie i posprawdzać ich wartości :)
Ja mam metodę protected virtual Debug w każdej klasie i publiczny bool debug. Jeśli ‘debug == true’, to metoda Debug jest włączana do potoku i na ekranie na bieżąco wyświetlają mi się wszelkie informacje o obiektach, począwszy od macierzy i kontenerów obiektów 3D a skończywszy na widgetach. Kiedy zechcę mogę kliknąć wybraną zmienną i ją zmienić. Jest to na stałe wbudowane w silnik i we wszelkie gry na nim pisane.
Ale musisz ręcznie wklepać ciało tej metody :) Ja chcę zrobić tak byś mógł coś podobnego zrobić z poziomu konsoli -wylistować/zmienić wartości pól klasy, ale bez jakiegokolwiek dodatkowego kodu w klasie którą się będziemy bawić - tak całkiem z zewnątrz będzie to załatwiane, niskopoziomowo na pamięci.
Riddle: czasem taki sposób jest lepszy. Naprawdę dużo bym dał by parę spraw sobie pooglaać w runtime'ie - wiele by mi to dało. A  z poziomu debuggera czasem ciężko się do tego dokopać.