vb.net - Cómo haría TDD con un objeto COM OLE

testing

Question

Tengo un objeto COM OLE que al intentar escribir un contenedor, he decidido comenzar a usar TDD para escribir el código, ya que creo que me dará un mejor sentido de dirección con lo que trato de escribir. El objeto COM tiene una interfaz como esta:

Interface Mapinfo
Sub [Do](ByVal cmd As String)
Function Eval(ByVal cmd As String) As String
End Interface

El comando [Do] tomaría algo así como el siguiente

Mapinfo.Do("OpenTable("""C:/Temp/MyTable.TAB""")")

Ahora estoy intentando escribir un contenedor para que haya una función como esta:

Mapinfo.OpenTable("C:/Temp/MyTable.TAB")

Ahora mi principal problema que tengo es que cada vez que quiero escribir una prueba nueva y un código tengo que crear una instancia del objeto OLE, esperar a que la aplicación se inicie (30 segundos +), probar mi pequeña función , cierre y deseche el objeto OLE, cambie el código y vuelva a ejecutarlo.

Mi pregunta es: ¿hay una forma mejor de hacer todo esto sin tener que iniciar la aplicación OLE todo el tiempo? He oído hablar de objetos simulados, pero realmente no lo he investigado mucho, ¿me ayudarían aquí? ¿Si es así, cómo?

EDITAR: Ahora me he dado cuenta de que tendré que hacer un objeto de simulación para Mapinfo, mi pregunta es ¿cómo puedo hacer un objeto de simulación que pueda tomar diferentes cadenas formateadas? ¿Cómo me ayudará esto a verificar que el código en mi envoltorio sea correcto?

Answer 1

Sí, los objetos simulados ayudarían. Básicamente, crea un objeto Mapinfo falso burlándose de la interfaz de Mapinfo (debe cambiar el nombre de IMapInfo, por cierto).

A continuación, instruye que se burlen de qué llamadas esperar, y qué resultados devolverá (si corresponde). También puede crear pruebas donde el simulacro arroja excepciones o hace otras cosas que son difíciles de invocar utilizando el objeto real.

Los dos marcos de burla de .NET grandes (y gratuitos) son MoQ y Rhino Mocks . Rhino es más maduro y tiene más formas de configurar burlas. MoQ es el recién llegado y tiene un conjunto de características más pequeño y menos formas de establecer expectativas que Rhino.

Personalmente, creo que MoQ es mejor para el recién llegado que para burlarse. Es relativamente fácil de entender, toda la documentación disponible es relevante para la versión actual (buscar tutoriales de Rhino y obtener basura de hace años que ya no se aplica) y funciona bien.