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

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 14:42:31
kurka... to jak programujesz bez testów?

Jak widać całkiem dobrze mu to wychodzi :)

Offline Mr. Spam

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

RageX

  • Gość
# Sierpień 14, 2007, 16:35:28
Dla mnie tez to bardzo dziwne - w moim przypadku sprawa wyglada tak ze napisze jedna funkcje i od razu patrze na wszystkie sposoby czy dziala dobrze zeby potem sie niepotrzebnie nie przekopywac przez te funkcje jak sie okaze ze "ogolnie calosc" nie chce dzialac :)

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 16:39:57
rotfl - yarpen, a możesz mi proszę wytłumaczyć czym się różni:
Cytuj
We have a nice auto test system, which just grabs latest code/data every day at 11pm (at 3 different machines), runs several scenarios and records basic performance counters, insertes results into MySQL database, creates some graphs and sends e-mails. When I get to work I grab a drink and can see the latest results.
Od tego co ja zaproponowałem? :)

Offline yarpen

  • Użytkownik

# Sierpień 14, 2007, 16:49:33
rotfl - yarpen, a możesz mi proszę wytłumaczyć czym się różni:
Cytuj
We have a nice auto test system, which just grabs latest code/data every day at 11pm (at 3 different machines), runs several scenarios and records basic performance counters, insertes results into MySQL database, creates some graphs and sends e-mails. When I get to work I grab a drink and can see the latest results.
Od tego co ja zaproponowałem? :)
To jest testowanie wydajnosci na tych samych maszynach, w tych samych dokladnie warunkach. Nie porownujemy pomiedzy komputerami, mamy po prostu 3 konfiguracje low/med/hi z roznymi poziomami detali. To dosyc znaczaca roznica od porownywania screenshotow z 30 roznych konfiguracji z tym wzorcowym.

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 16:52:57
To jest testowanie wydajnosci na tych samych maszynach, w tych samych dokladnie warunkach. Nie porownujemy pomiedzy komputerami, mamy po prostu 3 konfiguracje low/med/hi z roznymi poziomami detali. To dosyc znaczaca roznica od porownywania screenshotow z 30 roznych konfiguracji z tym wzorcowym.
Mi m.in. o coś takiego chodziło - ale dodatkowo jeśli rozłożyć by to na ciut różniące się maszyny, ale podobne klasowo to monitoroanie dużych odstępstw od poprawności/wydajnosći może we wczesnej fazie developingu uwypuklić wiele problemów :) Chcę po prostu pójść krok dalej niż wy :)

Offline yarpen

  • Użytkownik

# Sierpień 14, 2007, 17:09:42
To jest testowanie wydajnosci na tych samych maszynach, w tych samych dokladnie warunkach. Nie porownujemy pomiedzy komputerami, mamy po prostu 3 konfiguracje low/med/hi z roznymi poziomami detali. To dosyc znaczaca roznica od porownywania screenshotow z 30 roznych konfiguracji z tym wzorcowym.
Mi m.in. o coś takiego chodziło - ale dodatkowo jeśli rozłożyć by to na ciut różniące się maszyny, ale podobne klasowo to monitoroanie dużych odstępstw od poprawności/wydajnosći może we wczesnej fazie developingu uwypuklić wiele problemów :) Chcę po prostu pójść krok dalej niż wy :)
To akurat slusznie. Gdybysmy zrobili to wczesniej, nie musielibysmy sie meczyc teraz  ;)

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 17:13:13
Teraz mi się przypomniał jeden myk - Geometry Shader i Stream Out w pierwszej generacji kart SM4.0 sa do 20 razy szybsze w ATI niby... Masakra po prostu - nie chciałbym pracować na ATI żeby po miesiącu się okazało że na GF produkcja jest nie do życia kompletnie - właśnie takie motywy chciałbym atakować.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 14, 2007, 17:14:09
Cytuj
Dla mnie tez to bardzo dziwne - w moim przypadku sprawa wyglada tak ze napisze jedna funkcje i od razu patrze na wszystkie sposoby czy dziala dobrze zeby potem sie niepotrzebnie nie przekopywac przez te funkcje jak sie okaze ze "ogolnie calosc" nie chce dzialac
Maxest: podejście na zasadzie "patrzę" nic Ci nie daje. Przede wszystkim nie daje Ci pewności, że ten kod faktycznie działa poprawnie. Inaczej będziesz go oceniał i analizował, gdy jesteś zmęczony, a inaczej gdy jesteś wypoczęty. Zresztą w głowie nie jesteś w stanie przewidzieć wszystkiego. A jak raz sobie napiszesz testy i zrobisz ich automatyzację (w mniejszym lub większym stopniu) to będziesz miał pewność, że kod jest ok. I że taki pozostanie po zmianach w nim wprowadzonych, po integracji z kodem innych programistów itp. A jak znajdziesz w nim buga i go naprawisz, to dowalisz jeszcze acceptance-testy i wszystko "pozostanie" po staremu.

Cytuj
Teraz mi się przypomniał jeden myk - Geometry Shader i Stream Out w pierwszej generacji kart SM4.0 sa do 20 razy szybsze w ATI niby...
Taaa a karty nVidii swoje kosztowały... :/

Offline yarpen

  • Użytkownik

# Sierpień 14, 2007, 17:19:13
Cytuj
Dla mnie tez to bardzo dziwne - w moim przypadku sprawa wyglada tak ze napisze jedna funkcje i od razu patrze na wszystkie sposoby czy dziala dobrze zeby potem sie niepotrzebnie nie przekopywac przez te funkcje jak sie okaze ze "ogolnie calosc" nie chce dzialac
Maxest: podejście na zasadzie "patrzę" nic Ci nie daje. Przede wszystkim nie daje Ci pewności, że ten kod faktycznie działa poprawnie. Inaczej będziesz go oceniał i analizował, gdy jesteś zmęczony, a inaczej gdy jesteś wypoczęty. Zresztą w głowie nie jesteś w stanie przewidzieć wszystkiego.
To jest akurat sredni argument, bo jezeli jestes zmeczony, to Twoj test rowniez moze zawierac bledy (o tym elemencie wszystkie ksiazki milcza. Bledny test jest gorszy niz jego brak, bo daje falszywe poczucie bezpieczenstwa). No i skoro przewidziec wszystkiego nie jestes, to testu tez nie napiszesz.

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 17:26:48
No i skoro przewidziec wszystkiego nie jestes, to testu tez nie napiszesz.

Przy czym testy wymagają zupełnie innego podejścia do tematu. Jeżeli ktoś podejdzie do tego tylko z poziomu kodu który napisał to ani nie zauważy błędów ani nie napisze dobrych testów. Trzeba trochę pohax0rzyć, pobawić się w reverse engeenering - uderzać w problematyczne kwestia dla naszego kodu, algorytmu czy całości sytuacji. Podczas zwykłego wertowania kodu pewnie na wszystko nie wpadniesz, ale jak masz doświadczenie w pisaniu testów i się za to rzetelnie weźmiesz to napiszesz tak fajne fuzzery że kod będzie reprezentował wysoką jakość.
Moim zdaniem jednak największym problem jest czas wdrażania testów. Pamiętajmy że np. klasa to czarna skrzynka, i jako taką chcielibyśmy ją testować, ale przecież istnieje szereg często skomplikowanych zależności i odtworzenie jej jakiegoś środowiska istnienia itp może być czasem zbyt kosztowne.

RageX

  • Gość
# Sierpień 14, 2007, 17:27:41
yarpen: Natomiast brak testów, kończy się separowaniem kodu, tworzeniem testów.

Edit:
mINA87: Dlatego ja optuje za prostymi testami układanymi w hierarchie. Robię odsiew... coś tam pewnie przejdzie... odkryje to na wyższym poziomie hierarchii, będzie więcej do sprawdzania. Ale testy mogę tworzyć dużo szybciej.
Właściwie, moje testy nigdy nie spełniają warunków formalnych, sa proste i w zasadzie tylko do mojego użytku. :)
« Ostatnia zmiana: Sierpień 14, 2007, 17:35:07 wysłana przez RageX »

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 14, 2007, 17:35:48
Yarpen: Może użyłem zbyt dużego skrótu myślowego:
Bardziej miałem na myśli to, że nawet dokładna analiza kodu nie daje 100% pewności co do jego poprawności. Jeśli nawet sprawdzimy kod w kilku przypadkach, które jesteśmy w stanie w danej chwili wymyśleć, to nadal możemy być bardzo dalecy od prawdy. Zwykle też co zauważyłem, że programiści chętniej sprawdzają kod w tych przypadkach, w których on działa, często pomijając sytuacje nietypowe czy wręcz wydawałoby się absurdalne. Często robią też to pobieżnie, byle nie znaleźć w kodzie błędu. Natomiast w testach poza przypadkami szczególnymi możemy się wspomóc danymi testowymi wygenerowanymi automatycznie, za pomocą mniej lub bardziej wyrafinowanej techniki. Jeśli zatem sprawdzimy kod dla kilku setek przypadków możemy powiedzieć, że prawie na pewno działa poprawnie. Choć zwykle aż taka szczegółowość testów jest zbyteczna. Zresztą znów nie wiem czy napisałem to co miałem na myśli ;)

Ponadto:
Wszystkie metodologie podkreślają, że programista nie powinien zbyt często pracować poza godzinami. Innymi słowy nie powinien być zmęczony (więc faktycznie bezsensowny argument podałem). Jeśli jest do tego zmuszony, tzn. że ktoś stworzył nierealny dead-line = błąd kierownictwa, a nie programisty.

Cytuj
Moim zdaniem jednak największym problem jest czas wdrażania testów. Pamiętajmy że np. klasa to czarna skrzynka, i jako taką chcielibyśmy ją testować, ale przecież istnieje szereg często skomplikowanych zależności i odtworzenie jej jakiegoś środowiska istnienia itp może być czasem zbyt kosztowne.
Nie do końca się zgodzę. Jeśli unit-testy tworzymy przed napisaniem właściwego kodu zwykle wydatnie skracamy samą implementację tego kodu (bo jest on już wtedy dobrze przemyślany - wystarczy przelać te myśli na ekran). Choć to może wydawać się wielu osobom dziwne, jest już dziś (tak od 4-5 lat) praktyką. Kod w ten sposób napisany ma także zwykle dużo mniej błędów, bo przewidziano w nim wszystkie sytuacje nietypowe.

A tak poza tym to niezły offtop się zrobił ;)
« Ostatnia zmiana: Sierpień 14, 2007, 17:43:47 wysłana przez Riddlemaster »

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 17:43:05
Cytuj
Moim zdaniem jednak największym problem jest czas wdrażania testów. Pamiętajmy że np. klasa to czarna skrzynka, i jako taką chcielibyśmy ją testować, ale przecież istnieje szereg często skomplikowanych zależności i odtworzenie jej jakiegoś środowiska istnienia itp może być czasem zbyt kosztowne.
Nie do końca się zgodzę. Jeśli unit-testy tworzymy przed napisaniem właściwego kodu zwykle wydatnie skracamy implementację tego kodu. Choć to może wydawać się wielu osobom dziwne, jest już dziś (tak od 4-5 lat) praktyką. Kod w ten sposób napisany ma zwykle dużo mniej błędów, bo przewidziano w nim wszystkie sytuacje nietypowe.
Tzn masz rację i na pewno napisanie testów najpierw pozwala wyeksponować wiele kwestii - w 100% się zgadzam.
Chodzi mi o sam sposób testowania. Jeśli tworzymy obiekty które są tworzone przez jakieś wyspecjalizowane fabryki itp to żeby pounittestować musimy je trochę pohaczyć, albo wykorzystać nasze fabryki do unit testów. Oba albo wymagają pewnych nakładów pracy, albo są niezbyt eleganckie.
Chyba że - wykorzystać warstwę refleksji C++ i low-levelowo pohaczyć składowe klasy ]:-> - fajny pomysł na framework do unit testów kodu C++ :P Musze w końcu tą refleksję nad C++ napisać :)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 14, 2007, 17:45:39
Cytuj
fajny pomysł na framework do unit testów kodu C++  Musze w końcu tą refleksję nad C++ napisać
Zapoznaj się z UnitCPP ;) Można to podpiąć bez jakiegokolwiek haczenia kodu.

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 17:53:27
Cytuj
fajny pomysł na framework do unit testów kodu C++  Musze w końcu tą refleksję nad C++ napisać
Zapoznaj się z UnitCPP ;) Można to podpiąć bez jakiegokolwiek haczenia kodu.
Ciekawy framework, ale chyba nie rozwiązuje wszystkich problemów o których myślę.
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? Zaprzyjaźniać czy odstawiać innych kombinacji też nie chcę (wiem, wiem - wymagający jestem :F).