2009-02-11 10 views
9

Estamos desarrollando aplicaciones para su uso dentro de AutoCAD. Básicamente, creamos un proyecto de biblioteca de clases y cargamos el .dll en autoCAD con un comando (NETLOAD).Mejores prácticas con pruebas unitarias en API de software de terceros (AutoCAD)

Como lo tanto, podemos utilizar los comandos "Paletas", controles de usuario, formularios, etc ...

Autodesk proporciona una API a través de algunos de DLL, corriendo en su directorio del programa. Al hacer referencia a estos dll, solo puede llamar al dll en tiempo de ejecución mientras carga su aplicación en AutoCAD (esta es una seguridad de licencia de AutoDesk).

Para nosotros, mientras desarrollamos, esto no es un problema, tenemos que probar visualmente en el contexto de AutoCAD, así que simplemente configuramos las propiedades de depuración para que comiencen acad.exe y carguen nuestra DLL con una secuencia de comandos en el parámetros acad.exe.

El problema es que al intentar probar la unidad de nuestro código, NUnit o mstest no se ejecutan desde el contexto de AutoCAD y tampoco pueden iniciarlo. Existe una herramienta llamada Gallio, que ha proporcionado una interfaz con AutoCAD, de modo que puede ejecutar la prueba unitaria a través de IPC con Canalizaciones con nombre.

Sin embargo, esta solución es, para mí, demasiado molesta. Quiero poder escribir pruebas rápidamente sin tener que abandonar mi querido IDE.

Entonces, ¿qué, desde una "buena vista de diseño" sería un buen enfoque para este problema? Estoy pensando que básicamente necesitaría una base de código comprobable que no haga referencia a los dll de AutoCAD y una no verificable que haga referencia a los dll de AutoCAD no comprobables.

Estoy seguro de que hay formas de hacer que esto funcione: (IOC, DI, Adapter Pattern,.) Simplemente no conozco estos principios en profundidad y, por lo tanto, no sé qué ruta satisfará mejor a mi propósitos y metas.

Respuesta

8

El primer paso es clasificar su código para las piezas que necesitan AutoCAD y las piezas que son realmente independientes. Cree pruebas unitarias para las partes independientes como lo haría normalmente.

Para las otras partes, necesita maquetas que se comporten como AutoCAD. Hazlos lo más simples posible (por ejemplo, solo devuelve las respuestas correctas en los métodos sin hacer ningún cálculo). Ahora, necesita varios conjuntos de clases:

  1. Un conjunto de interfaces que utiliza el código para lograr algo (por ejemplo, cargar un dibujo).

  2. Un conjunto de implementaciones para dicho conjunto de interfaces que llaman a los dlls de AutoCAD.

  3. Conjunto de clases que prueban las implementaciones en el contexto de AutoCAD. Simplemente cree una IU pequeña con un par de botones donde puede ejecutar este código. Se usa para asegurarte que tus maquetas hacen lo correcto. Registre los parámetros del método y los resultados en algún archivo para que pueda probar cómo responde AutoCAD. Si se rompe una maqueta, puede usar este código para verificar qué está haciendo AutoCAD y puede usarlo como referencia al desarrollar las maquetas.

  4. Cuando sepa cómo responde AutoCAD, cree las maquetas. En sus pruebas, créelos con los resultados deseados (y errores, para que pueda probar el manejo de errores también). Por lo tanto, cuando tenga boolean loadDrawing(File filename), cree una maqueta que devuelva true para el nombre de archivo exists.dxf y false para cualquier otra cosa.

  5. Use una fábrica o DI para indicarle a su código de aplicación qué implementación usar. Tiendo a tener una gran clase de configuración global con muchos campos públicos donde simplemente almaceno los objetos para usar. Puedo configurar esto desde el principio, es rápido, es fácil de entender. Si necesita crear objetos en tiempo de ejecución, coloque fábricas en la clase config que genere los objetos por usted, para que pueda intercambiarlos.

+0

Gracias por su respuesta. Voy a mirar en esa dirección. Tengo un problema con su comentario en 3D: dado que no estamos simplemente abriendo un archivo, sino usando transacciones, editando objetos, etc. ¿Debería crear un contenedor para cada objeto Acad entonces? – Bertvan

+2

@Bertvan: Encuentre la respuesta a esta pregunta: ¿Qué tan seguro está de que su código se rompa para cada objeto de ACad? Si no está seguro, escriba una prueba. Cuando se vuelve aburrido, detente. Cuando encuentre nuevos errores y no esté seguro nuevamente, agregue más pruebas. Debes encontrar * tu * mejor camino. –

0

Escribí ... y luego se rompió ... un Test runner for AutoCAD. Está en https://github.com/CADbloke/CADtest. Si estás interesado en eso, dame un empujoncito y lo arreglaré más rápido. Estoy esperando el lanzamiento de NUnit v3 antes de abordarlo.

Si restablece el 3er compromiso en ese repositorio (creo) y juega con él desde allí, debería ejecutarse.

Cuestiones relacionadas