Ortogonalità dei test unitari vs. concisione dei test unitari

Question

Ortogonalità dei test unitari vs. concisione dei test unitari

#1 da (10 voti)
#2 da (1 voti)
#3 da (0 voti)

14

Sto scrivendo test unitari per un sistema di guida per un videogioco. Il sistema ha diversi comportamenti (evita quest'area a causa della ragione A, evita quest'area a causa della ragione B, ciascuno aggiungendo un po 'di contesto a una mappa della regione.) Una funzione separata quindi analizza la mappa e produce un movimento desiderato. p>

Ho difficoltà a decidere come scrivere i test unitari per i comportamenti. Come suggerisce TDD, mi interessa solo il modo in cui i comportamenti influenzano il movimento desiderato. Ad esempio, evitare-perché-della-ragione-A dovrebbe comportare un allontanamento dalla cattiva posizione suggerita. Non mi interessa davvero come o perché il comportamento aggiunge contesto alla mappa, solo che il movimento desiderato è lontano dalla posizione.

Quindi i miei test per ogni comportamento impostano il comportamento, lo fanno scrivere sulla mappa, quindi eseguono la funzione di analisi della mappa per calcolare il movimento desiderato. Se quel movimento soddisfa le mie specifiche, allora sono felice.

Tuttavia ora i miei test dipendono dal corretto funzionamento di entrambi i comportamenti e dal corretto funzionamento della funzione di analisi della mappa. Se la funzione di analisi fallisce, otterrei centinaia di test falliti piuttosto che un paio. Molte guide per la scrittura di test suggeriscono che questa è una pessima idea.

Tuttavia, se provo direttamente contro l'output dei comportamenti prendendo in giro la mappa, allora sicuramente sto accoppiando troppo strettamente all'implementazione? Se riesco a ottenere lo stesso movimento desiderato dalla mappa usando un comportamento leggermente diverso, i test dovrebbero comunque passare.

Quindi ora soffro di dissonanza cognitiva. Qual è il modo migliore per strutturare questi test?

tdd unit-testing

posta tenpn 10.08.2011 - 12:55

fonte

3 risposte

1

Questo tipo di test è il motivo per cui sono stati inventati i mock. L'idea principale: scrivi un mock per il tuo oggetto (mappa, comportamento, carattere, ...), quindi scrivi test usando quella simulazione anziché l'oggetto reale. Le persone a volte chiamano mocche mocciose, e credo che ci siano altre parole per entrambi.

Nel tuo caso, dovresti scrivere una simulazione per la mappa ogni volta che hai bisogno di testare i comportamenti, e altre mazze per i comportamenti ogni volta che vuoi testare la mappa. Le tue prese in giro sarebbero idealmente molto più semplici dei comportamenti reali che stai prendendo in giro, solo incorporando metodi o variabili che effettivamente ti servono per quel test. Potrebbe essere necessario scrivere un falso diverso per ogni singolo test, oppure potresti essere in grado di riutilizzare alcuni mock. Indipendentemente da ciò, dovrebbero essere adatti al test e non dovrebbero cercare di essere il più possibile simili al comportamento reale.

Se hai incluso alcuni esempi di mappe o comportamenti, forse qualcuno potrebbe fornire esempi di mock che potresti scrivere. Non io, dato che non ho mai programmato un videogioco più avanzato di Pong, e anche allora stavo seguendo un libro, ma forse qualcuno esperto in entrambe le fasi di test e sviluppo del gioco.

risposta data 13.10.2014 - 19:27

fonte

0

Penso che tu provi a testare cose che sono di livello molto più alto di una unità.

La maggior parte dei test comportamentali richiederebbe un po 'di intelligenza, per capire se si comportava correttamente. Questo non può essere fatto facilmente utilizzando test automatici.

risposta data 10.08.2011 - 13:12

fonte

Leggi altre domande sui tag tdd unit-testing

Chiamando più servizi asincroni in parallelo Come funzionano i filtri di fioritura scalabili?

score 10 · Accepted Answer

Nel mondo ideale, avresti davvero un set di prove unitarie perfettamente ortogonali, tutte sullo stesso livello di astrazione.

Nel mondo reale, di solito hai test su molti diversi livelli dell'app, quindi spesso i test di livello più alto esercitano funzionalità che sono già state testate da test dedicati di livello inferiore. (Molte persone preferiscono chiamare test di sottosistema / integrazione test di livello superiore piuttosto che test di unità, tuttavia possono comunque essere eseguiti sullo stesso framework di test delle unità, quindi dal punto di vista tecnico non c'è molta differenza.)

Non penso che questa sia una brutta cosa Il punto è di far testare il codice nel modo migliore che si adatta al tuo progetto e alla tua situazione, non di aderire "al modo ideale".