Este es un seguimiento de esta pregunta. Allí estaba preguntando cómo hacer pruebas unitarias cuando tienes una biblioteca de algoritmos científicos. Tengo un problema similar ahora pero con un proyecto diferente.
Estoy trabajando en una abstracción del marco del motor de gráficos 3D para DirectX, OpenGl, WebGl, Silverlight, WPF, y básicamente cualquier API 3D que exista, en C #, llamada Rendering .NET . El escenario es el siguiente, el proyecto está siendo desarrollado por un pequeño equipo de colegas míos, todos trabajando en la misma oficina. Todos somos científicos informáticos, no nos interesa mucho la comunidad y las prácticas de ingeniería de software. Incluso tuve dificultades para convencerme de cambiar de Subversion a Git y publicar el proyecto en Codeplex. El proyecto se está haciendo grande (alrededor de 80K líneas de C #), y ahora cubre la mayor parte de DirectX y OpenGl hasta Shader Model 5.0, por lo que no es un proyecto de un solo hombre como el que se describe en la pregunta vinculada. También queremos alentar a la comunidad de código abierto a colaborar.
Hasta ahora hemos estado probando escribiendo pequeñas aplicaciones que implican inicializar todos los dispositivos y recursos, configurar una escena y dibujar. La cuestión es que no sé cómo hacerlo diferente, es decir, cómo diseñar pequeños casos de prueba que prueben características específicas del marco, como la asignación de recursos, la teselación primitiva, la compilación de sombreadores, etc., sin tener que recrear el Inicialización completa del motor. Para algunos de estos casos, puedo pensar en simulacros útiles, pero en general, ¿cómo puedo probar la corrección de un algoritmo de renderizado cuando la salida es visual (una imagen o una escena animada)? En este momento, lo más inteligente que hemos encontrado es renderizar la misma escena a un procesador de software, DirectX y OpenGl, y compararlos píxel por píxel,
Entonces, ¿cuál es el enfoque de prueba "correcto" aquí?
fuente
Respuestas:
El enfoque de prueba "correcto" sería desacoplar su lógica de dibujo de las llamadas de DirectX u OpenGL, para que pueda burlarse de esta última (y como otro caso de uso, use la misma lógica de negocios para DirectX u OpenGL).
No desea probar si DirectX u OpenGL funcionan correctamente, ese es el trabajo de Microsoft. También desea que el código de inicialización de su dispositivo se escriba y pruebe solo una vez (y luego se reutilice), por lo que una prueba manual de esa parte debería ser asequible. Si también desea probar esa parte automáticamente, use su enfoque de píxel por píxel, pero con un dibujo de prueba muy simple. Por lo tanto, concéntrese en escribir pruebas de regresión automatizadas para su lógica de dibujo desacoplada, que le brindará el mayor beneficio.
Entonces, la idea es dividir su código en componentes realmente independientes : su inicialización de DirectX no debe estar acoplada a la lógica de dibujo, y la lógica de dibujo no debe depender de DirectX, esto hace que su programa sea comprobable.
EDITAR: encontré esta publicación anterior en pruebas unitarias para el código OpenGL, solo hubo algunas respuestas, pero tal vez traerá algunas ideas adicionales.
fuente