Spiludvikling.dk

Jeg er begyndt at udvikle en del tests til mit spil og i princippet virker det fint nok men engang imellem sker der nogle mærklige ting.

For eksempel kan en unit test fejle, hvis jeg har valgt at kører flere tests efter hinanden men hvis jeg kører den igen alene vil den bestå testen. Det virker for mig vild mærkligt da jeg ikke kan finde ud af hvorfor det skulle ske.

Engang imellem sker det også at en test simpelthen bare ikke svarer og jeg bliver nødt til at anullere testen, ændre nogle af mine parametre og køre den igen for at få det til at virke.

Yderligere hvis jeg debugger mine tests vil de aldrig bestå, der er dele af mine tests jeg ikke kan debugge så jeg begynder at tro at jeg enten ikke sætter mine tests op korrekt eller der er en fejl i kompileren af unit testsene.

Når det så er sagt, så er unit testing utrolig effektiv og er en super god måde at finde fejl i sin kode, samt sikre sig ikke at lave rod i noget kode som allerede virker. Jeg kunne dog godt ønske mig at det ikke var så 'sart' at køre og at man kunne debugge det lidt bedre.

Er der eventuelt nogle der har erfaring med unit testing i Visual Studio C++ (Native) som muligvis kan kaste lidt lys på mine problemer?

Har ikke arbejdet med Unit tests i C++, men har over 10 års erfaring med at gøre det i C#. Håber jeg kan hjælpe lidt selvom det er et andet sprog.

At du har tests der fejler nogle gange når de køres med andre skyldes typisk at der er en eller anden ekstern resource de to tests deler. Det kan være alt fra globale/statiske/singleton klasser til en fil. Hvis tests er opdelt i deres egne klasser kan det også være parametre i selve klassen. Det er meget vigtigt at være opmærksom på at alle tests skal foregå i total isolation.

Hvis det betyder at et eller andet environment man sætter op til testen skal laves fra scratch og det er dyrt - så skal man fokusere på at mindske den afhængighed der er af det ved at splitte koden mere op.

Automatiserede tests er guld værd, men det kan godt tage noget tid at lære hvordan man gør det rigtigt effektivt så man får mest muligt ud af det.

Mange tak for dit input. Det giver meget mening at flere tests ville fejle, hvis de kørte på samme tid og brugte samme resurser. Dette er dog ikke tilfældet, da ingen af mine tests køre på samme tid. De vil alle starte op og afslutte før en ny test bive påbegyndt (i teorien).

Jeg har dog på fornemmelsen at DLL filen (som mit spil bliver kompileret om til af Visual Studio) af en eller anden grund er utrolig 'sart' og ikke altid bliver fjernet fra hukommelsen før en ny test bliver påbegyndt. For når jeg kører testene kan jeg næsten på forhånd udpege hvilke tests der vil fejle. De første tests i rækken vil nemlig altid opføre sig på normalvis, hvis en tests fejler på mærkværdigvis, er det altid en af de sidste tests i rækken.

Mine unit tests virker ganske fint for at teste individuelle funktioner samt klasser, hvilket jeg tror der er den påtænkte metode at benytte unit test delen på. For de tests, der nogle gange fejler, er det altid mine gameplay tests. Altså store tests, hvor hele spillet bliver loaded ind i hukommelsen og bliver spillet automatisk.

Jeg kunne forestille mig at det nok ikke er hensigten at teste på denne måde, men når det virker (hvilket det ofte gør) er det utrolig effektivt, for ikke blot finder den evt. fejl, men den vil også kunne afsløre balancen i gameplayet. Jeg kan dermed automatisk spille spillet x antal gange og dermed sammenligne resultaterne og for at finde en balanace i spillet.

Det giver meget god mening at det er Gameplay tests som fejler for dig. Når man gør det er det i hvert fald meget vigtigt at man enten sikrer at spillet er lukket 100% ned og alt er ude af hukommelsen før næste test - eller at man har en metode i spillet til at resette alt 100% så man kommer til en "kendt state" hvor testen kan begynde uden problemer.

Man vil vildt gerne have det sidste, fordi det naturligvis vil spare tid når der testes. Det er en væsentlig parameter at tests kan gennemføres hurtigt og konsistent for at have værdi.

Det er muligt du kan omgå problemet ved at lave et kunstigt delay mellem hver af de lange tests, så du er sikker på at alt er renset fra hukommelsen.

Det er ikke en dårlig ide at lave en kunstig tidsforsinkelse mellem mine tests.

Engang imellem vil en test stoppe med at svare men det er altid til sidst i testen at dette sker. Dette har sikkert igen noget med at DLL filen ikke bliver lukket ned ordenligt, for jeg kan se at spillet har udført, hvad den skulle men i det sekund den prøver at lukke spillet ned, vil den engang bare hænge uden at svare, og jeg er dermed nødsat til manuelt at anullerer testen og prøve igen.

Hvilket kan være irriterende og ret tidskrævende , specielt når jeg har hundredevis af gameplay tests at gå igennem, der alle kan tage op til et minut at fuldføre. Hvis jeg spiller spillet manuelt og samme situation opstår (som der blev testet for) er der slet ingen problemer.

Før jeg laver en backup eller comitter nyt kode, går jeg altid igennem alle mine tests, for at se om jeg har ødelagt noget i spillet ved et uheld, så jeg kommer til at støde ind i disse problemer ret ofte.

Unit tester du selv dine spil ofte?

Jeg synes det lyder som om du skal prøve at sikre at det lukker ordentligt ned om det er med en forsikelse eller ved en anden måde er ligemeget.

Det er vigtigt at alle tests bliver kørt når der bliver lavet ændringer. Jo hurtigere man finder ud af at noget er gået i stykker, jo lettere er det at fikse det. Jeg sætter typisk CI op så en eller anden maskine tygger den igennem efter hvert commit. Det kan være sværere med de tests der tager lang tid at køre, men der kan man evt. sætte dem op til at køre dagligt.

Jeg benytter mig altid af unit tests i større eller mindre grad. Både til spil og til andre ting jeg gør. Altid til min kernekode, som jeg sørger for er godt isoleret fra alt hvad der hedder UI/fysik/animation eller andre ting der er besværlige at unit teste. Og så sørger jeg for at strukturere det så det er let at koble de ting på efterfølgende.

Det er kun få gange det er lykkedes for mig at have ordentlig automatiseret gennemspilning af spillet, hvor det har været rigtigt brugbart. Ofte har det bare været mere arbejde end det har været værd.

Hey.
Jeg skal til at teste om ikke så længe,
Kender i nogen steder hvor man kan finde en slags kom godt i gang med tests eller slå problemer op?
inden jeg begynder at stille en masse spørgsmål
jeg arbejder i Unity og Visual Studio C#.
Det ville virkeligt være en hjælp

Når du siger at du skal i gang med test lyder det som om du har gjort det lidt sværere for dig selv. Det er meget lettere at lave sine unit tests mens man laver koden og ikke retrofitte dem på kode der allerede er skrevet. Så har man en tendens til kun at teste på den måde man ved at koden er skrevet.

Desuden oplever man oftere at de ting man har skrevet er meget besværlige at teste fordi koden ikke er lavet til let at blive testet. Unit tests fungerer bedst hvis de kan være meget isolerede så man ikke skal sætte alt muligt op før den kode man skal teste fungerer.

Når det så er sagt, så er det ikke umuligt at få unit tests på kørende kode. Den måde jeg anbefaler at gribe det an på er dog at man ikke går i gang fra en ende af og laver udtømmelige unit tests på alt hvad man har skrevet. Basalt set er det komplet spild af tid. Forventeligt har man lavet en eller anden form for manuel test mens man har skrevet koden, så man har en ide om at den virker nogenlunde.

Derfor bør man fokusere på at intensivere sin manuelle test, og hver gang man så støder på en bug, så skriver man en test der pinpointer den bug, og så fikser man den. Det kan føre til at andet holder op med at virke, og så ved man hvor den næste test skal skrives.

Når man så støder på ting hvor der skal laves ny funktionalitet så skriver man tests til den funktionalitet man gerne vil have og løser problemerne der.

Slutteligt. Skal man refactore eller udskifte et eller andet modul. Så skriver man tests der viser at ens kode rent faktisk fungerer. Dem kan man støtte sig op ad så man kan se at det man ændrer ikke pludselig ødelægger noget.

Det lyder super let, men det er det desværre ikke. Der er lige så mange måder at skrive tests på som der er programmører tror jeg. Der er ikke en one size fits all metode. Og jeg kan desværre ikke lige pege på en god ressource til at kommme godt i gang. Jeg kan godt prøve at dele lidt mere om hvordan jeg griber det an hvis det har interesse.