Come si scrivono i test per una libreria grafica?

Sto scrivendo una libreria 2D OpenGL in Python. Tutto sta andando alla grande, e il codebase sta crescendo costantemente.Come si scrivono i test per una libreria grafica?

Ora voglio scrivere test di unità in modo da non accidentalmente portare nuovi bug mentre aggiustando altri/facendo nuove funzionalità. Ma non ho idea di come funzionerebbero con le librerie grafiche.

Alcune cose che ho pensato:

le immagini di riferimento di make e li confrontano con le immagini generati automaticamente nei test
sostituire le chiamate OpenGL con le dichiarazioni di registrazione e confrontare i registri

Ma entrambi sembrano un cattiva idea. Qual è il modo comune per testare le librerie grafiche?

fonte

2012-01-25 orlp

Le due cose che hai suggerito sono molto sensate per me, purché tu sia sicuro che ci sono veri risultati con cui confrontare. – lhf

L'approccio che ho usato in passato per il test a livello di componente è:

Utilizzare una divisa sfondo colorato, con pochi colori diversi.
Utilizzare i rettangoli colorati uniformi come oggetti grafici nei test (con alcuni colori diversi).
Posiziona i rettangoli in luoghi noti in cui puoi calcolare autonomamente la loro posizione proiettata nell'immagine.
Calcolare l'intensità prevista di ciascun canale di ciascun pixel (sfondo, primo piano o miscela).
Se si dispone di uno scenario di test che determina posizioni non arrotondate, utilizzare un confronto non accurato (ad esempio correlazione)
Utilizzare i calcoli per creare le immagini dei risultati previsti.
Confronta le immagini di output con le immagini dei risultati previsti.
Se si dispone di un effetto sfocatura, confrontare la somma di intensità anziché le intensità discrete.

Come indicato in Graham, le unità interne possono essere testate dall'unità prive di chiamate grafiche.

fonte

2012-01-25 09:48:19

Questi sono test di accettazione, e sono importanti, ma avrete anche bisogno dei test unitari, come ha detto Graham Reeds nell'altra risposta. –

Questi non sono test di accettazione, questi test testano un singolo componente e sono o test di integrazione o test unitari a seconda della definizione dell'unità sottoposta a test. Se gli algoritmi grafici sono scritti all'interno di shader o in codice OPENGL/DirectX, allora il codice non è sempre testabile separatamente dal processo di rendering grafico e questo è l'unico modo per testarlo da "unità". –

@RadomirDopieralski I test di accettazione dovrebbero essere sicuri che tu possa vedere qualcosa e non considererebbero ** posizioni esatte **, ** flussi white-box **, ogni singolo tipo di ** formato pixel **, effetto degli effetti filtro e così via. I test di sistema includeranno già l'applicazione sopra il motore grafico. –

Abbattere ulteriormente.

Le chiamate che fanno la grafica si basano su algoritmi - testare gli algoritmi.

fonte

2012-01-25 09:32:10

In realtà, nel mio caso è vero solo per metà. Nonostante abbia quasi tutte le funzionalità di base, utilizzo solo un algoritmo (nell'ordinamento degli sprite per il rendering in batch) e alcune cose come i pattern singleton. Quasi tutti gli altri codici rendono le chiamate OpenGL accessibili. – orlp

I singleton sono malvagi! Un contratto a cui ho lavorato ne ha usati quasi una dozzina. Reso un incubo. In C++ abbiamo creato un paio di funzioni basate su modelli che ti permettevano di inserire logger falsi o reali ecc. Per rendere possibile il test. Non so se puoi farlo in Python. –

Come si scrivono i test per una libreria grafica?

risposta

Problemi correlati