¿Cómo escribo las pruebas para una biblioteca de gráficos?

Estoy escribiendo una biblioteca OpenGL 2D en Python. Todo va bien, y la base de código está creciendo constantemente.¿Cómo escribo las pruebas para una biblioteca de gráficos?

Ahora quiero escribir pruebas unitarias para no traer nuevos errores al arreglar otros/crear nuevas funciones. Pero no tengo idea de cómo funcionarían con las bibliotecas de gráficos.

Algunas cosas que pensaban de:

imágenes hacen referencia y compararlos con capturas de pantalla generadas automáticamente en las pruebas
sustituir a las llamadas de OpenGL con declaraciones de registro y comparar los registros

Pero ambos parecen una mala idea. ¿Cuál es la forma más común de probar las bibliotecas de gráficos?

Fuente

2012-01-25 orlp

Las dos cosas que ha sugerido tienen mucho sentido para mí, siempre y cuando esté seguro de que hay verdaderos resultados con los que comparar. – lhf

El método que he utilizado en el pasado para las pruebas de nivel de componente es:

Utilice un fondo de color uniforme, con unos colores diferentes.
Utilice rectángulos de colores uniformes como objetos gráficos en las pruebas (con algunos colores diferentes).
Coloque rectángulos en lugares conocidos donde pueda calcular su posición proyectada en la imagen usted mismo.
Calcule la intensidad esperada de cada canal de cada píxel (fondo, primer plano o mezcla).
Si tiene un escenario de prueba que da como resultado posiciones no redondas, use una comparación no precisa (por ejemplo, correlación)
Use los cálculos para crear las imágenes de resultado esperadas.
Compare las imágenes de salida con las imágenes de resultado esperadas.
Si tiene un efecto de desenfoque, compare la suma de la intensidad en lugar de las intensidades discretas.

Según Graham, las unidades internas pueden ser verificadas por la unidad sin llamadas gráficas.

Fuente

2012-01-25 09:48:19

Esas son pruebas de aceptación, y son importantes, pero también necesitará las pruebas unitarias, como dijo Graham Reeds en la otra respuesta. –

Estas no son pruebas de aceptación, estas pruebas prueban un solo componente y son pruebas de integración o pruebas unitarias dependiendo de la definición de la unidad bajo prueba. Si los algoritmos gráficos se escriben dentro de sombreadores o en código OPENGL/DirectX, entonces el código no siempre se puede probar por separado del proceso de representación gráfica y esta es la única forma de probarlo en "unidad". –

@RadomirDopieralski Las pruebas de aceptación serían para asegurarse de que puede ver algo y no consideraría ** las posiciones exactas **, ** los flujos de la caja blanca **, cada tipo de ** formato de píxeles **, el efecto de los efectos del filtro y etc. Las pruebas del sistema ya incluirían la aplicación sobre el motor de gráficos. –

Disminuya aún más.

Las llamadas que hacen los gráficos dependerán de los algoritmos: prueba los algoritmos.

Fuente

2012-01-25 09:32:10

En realidad, en mi caso, eso es solo verdad a medias. A pesar de tener casi todas las funciones básicas, solo uso un algoritmo (en la clasificación de sprites para la representación por lotes) y algunas cosas como patrones de singleton. Casi todos los demás códigos hacen que las llamadas OpenGL sean accesibles. – orlp

¡Los singleton son malvados! Un contrato en el que trabajé usó casi una docena de ellos. Hecho prueba una pesadilla. En C++ creamos un par de funciones con plantillas que le permitían extraer loggers falsos o reales, etc. para hacer posibles las pruebas. No sé si puedes hacer eso en Python. –

¿Cómo escribo las pruebas para una biblioteca de gráficos?

Respuesta

Cuestiones relacionadas