Test delle unità su strutture di visualizzazione (grafica 3D)

8

Questo è un follow up di questa domanda. Vi stavo chiedendo come eseguire il test delle unità quando si dispone di una libreria di algoritmi scientifici. Ho un problema simile ora ma con un progetto diverso.

Sto lavorando a un'astrazione di framework per motori grafici 3D per DirectX, OpenGl, WebGl, Silverlight, WPF e praticamente qualsiasi API 3D è disponibile, in C #, chiamata Rendering .NET . Lo scenario è il seguente, il progetto è sviluppato da un piccolo gruppo di colleghi, tutti che lavorano nello stesso ufficio. Siamo tutti informatici, non molto nella comunità e nelle pratiche di ingegneria del software. Ho anche avuto difficoltà a convincere a passare da Subversion a Git ea pubblicare il progetto su Codeplex. Il progetto sta diventando grande (circa 80K linee di C #), e ora copre la maggior parte di DirectX e OpenGl fino a Shader Model 5.0, quindi non è un progetto one man come quello descritto nella domanda collegata. Vogliamo anche incoraggiare la comunità open source a collaborare.

Finora ci siamo testati scrivendo piccole applicazioni che prevedono l'inizializzazione di tutti i dispositivi e risorse, l'impostazione di una scena e il disegno. Il fatto è che non so come renderlo diverso, voglio dire, come progettare piccoli casi di test che testano caratteristiche specifiche del framework, come allocazione di risorse, tassellazione primitiva, compilazione di shader, ecc., Senza dover ricreare il intera inizializzazione del motore. Per alcuni di questi casi posso pensare a utili mock, ma in generale, come posso testare la correttezza di un algoritmo di rendering quando l'output è visivo (un'immagine o una scena animata)? In questo momento la cosa più intelligente che abbiamo scoperto è di rendere la stessa scena a un riproduttore di software, DirectX e OpenGl, e confrontarli pixel per pixel, ma piccole variazioni delle API rendono le immagini risultanti abbastanza diverse da fallire i test senza essere bug reali.

Quindi, qual è l'approccio di test "corretto" qui?

    
posta Alejandro Piad 26.02.2013 - 21:16
fonte

1 risposta

8

L'approccio di test "corretto" sarebbe quello di disaccoppiare la logica del disegno dalle chiamate DirectX o OpenGL, in modo da poter prendere in giro quest'ultimo (e come un altro caso d'uso, utilizzare la stessa logica di business per DirectX o OpenGL).

Non vuoi testare se DirectX o OpenGL funzionino correttamente - questo è il lavoro di Microsoft. Si desidera inoltre che il codice di inizializzazione del dispositivo sia scritto e testato una sola volta (e quindi riutilizzato), quindi un test manuale di tale parte dovrebbe essere conveniente. Se vuoi testare automaticamente quella parte, usa il tuo approccio pixel per pixel, ma con un disegno di prova molto semplice. Quindi concentrati sulla scrittura di test di regressione automatici per la tua logica di disegno disaccoppiata, che ti porterà il massimo beneficio.

Quindi l'idea è quella di dividere il tuo codice in componenti veramente indipendenti - l'inizializzazione di DirectX non dovrebbe essere accoppiato alla logica di disegno e la logica di disegno non dovrebbe dipendere da DirectX - questo rende il tuo programma verificabile.

EDIT: trovato questo precedente post sui test unitari per il codice OpenGL, c'erano solo poche risposte, ma forse porterà alcune informazioni aggiuntive.

    
risposta data 26.02.2013 - 23:09
fonte

Leggi altre domande sui tag