Il testing delle unità è qualcosa che amo ora dopo aver costretto me stesso a farlo nei progetti (e farlo sul lavoro) dopo aver visto le enormi ricompense che offre durante il refactoring e assicurare che le cose funzionino nel modo giusto.
In questo momento sto scrivendo un renderer software e non sono sicuro che ci sia un modo per configurarlo per essere testato. Ti darò un esempio di dove sono bloccato:
When scanning a polygon, it's most convenient right then and there after generating the scan to set the z-buffer and pixel from the texture as you're going along; when you're rendering a ton of polygons you need all the speed you can get.
The nice unit test way would be to return those scans so I could verify that each scan was where it was supposed to be, and check the data set along with it. Then for the next component that takes the scans, ...etc (more testing here)
Il problema qui è che tonnellate di scansioni di poligoni richiederanno molti intervalli per essere restituiti in vari casi, aggiungendo non solo un maggiore utilizzo della memoria, ma chiamate di funzioni aggiuntive che si ridurranno notevolmente quando gli utenti avranno risoluzioni più elevate. Facendo tutto in una volta, il renderer non soffoca, soprattutto nelle scene intensive di poligono.
Ho pensato ad alcuni possibili modi per aggirare questo problema, ma sembra che tutti abbiano il loro lato negativo:
-
Basta fare il modo ottimizzato e controllare i pixel finali alla fine di esso (che posso intercettare e controllare), ma poi se le cose si rompono ho intenzione di passare un sacco di tempo potenzialmente scoprendo esattamente dove qualcosa si è rotto.
-
Estendi le classi e ispeziona uno stub o in qualche modo intercettano i dati prima di passarli a disegnare su un buffer di pixel, tuttavia dovrò fare metodi virtuali (usando C ++) e questo introdurrà potenzialmente un sovraccarico Non ho bisogno attraverso un tavolo virtuale, a meno che non mi sbagli. Mi sto appoggiando a questo perché non so se il vtable sia effettivamente così costoso, ma potrei sbagliarmi quando si tratta del massiccio rendering di poligoni.
-
Mangia solo la penalizzazione delle prestazioni e forse alla fine del progetto, ottimizzalo dopo essere stato testato abbastanza, ma sembra che non sia molto TDD dal momento che il refactoring in un altro punto potrebbe creare problemi.
Voglio assicurarmi che tutti i miei elementi funzionino, ma finora devo raggrupparli insieme e fa sì che i test unitari non siano così appropriati ... poiché se qualcosa va storto, non so se il bordo del poligono lo scanner è rotto, o se l'algoritmo scanline è rotto, o il buffer z è stato impostato errato, o se la matematica per i prodotti vettoriali / incrociati / punti è sbagliata, ecc.
Inoltre non sono un fan di prendere uno screenshot alla fine e con un po 'di tolleranza per controllare se il renderer funziona correttamente (credo più di un test di integrazione). Probabilmente lo farò comunque, ma mi sembra troppo fragile, perché mi piace sapere "okay, questo sottomodulo è appena rotto" piuttosto che "l'intero oleodotto è appena rotto, prenderà il mio caffè e rimarrà comodo per le prossime ore cercando di scoprire dove ".
Supponendo che non mi manchi un po 'di "foresta dagli alberi" che è davvero ovvio, qual è il modo corretto per farlo?