unidad prueba olor

Estoy tratando de cambiar mi unidad de prueba de ArcGIS, y comenzar a usar simulaciones (yo uso rinoceronte).
Cuando comencé a escribir las pruebas, me di cuenta de que tenía que empezar a burlarme de muchos objetos, y un montón de métodos para pasar una prueba.
Por ejemplo - mi controlador recibe por primera vez un RelationshipClass (así que necesito derivadas La IWorkspace y devuelto IRelationshipClass), entonces también recibe una IFeature (Un talón), y llama finalmente stubRelClass.GetRelatedObjects(stubFeature), para devolver un ISet de otra IFeatures.unidad prueba olor

¿Es normal tener que andar tantos objetos y métodos solo para que pase? También siento como si realmente tuviera que pasar por alto el código (sí, sé que debería haber escrito primero las pruebas, todavía estoy probando este), para descubrir qué es lo siguiente y qué debo devolver. .

También estoy teniendo problemas con las clases de com burla que implementan más de una interfaz. En el código de producción, los QI entre las interfaces. ¿Cómo puedo crear un simulacro que implemente ambas interfaces en tiempo de ejecución?

Fuente

2009-06-29 Noam Gal

Dependiendo de su cadena de inyección, sí, a veces tiene que burlarse de muchos objetos. Sin embargo, si vas a varios niveles profundos, puede ser indicativo de un error de diseño; es posible que los objetos que se basan en datos que están a tres capas de tu API no estén ligeramente acoplados. Debería poder cortar la cadena de raíz simplemente devolviendo un objeto falso de algún tipo en algún momento que tenga las propiedades necesarias para las que necesita la capa que está probando.

También debería poder hacer la mayor parte de su burla en un método [SetUp] y luego hacer que cada prueba simplemente cambie una o dos cosas.

Para simular múltiples interfaces, Rhino tiene el concepto de un MultiMock. Creo que la sintaxis que está buscando es:

var mock = 
    MockRepository.DynamicMultiMock<MyType>(
       typeof(Interface1), 
       typeof(Interface2), 
       ....);

Fuente

2009-06-29 06:30:18 womp

Sobre la introducción de un objeto que corta los niveles de profundidad - que "salvar" a mí de burlarse de algunos de los objetos más (ya que éste cubrirá objeto para ellos), pero todavía había necesidad de burlarse de la la misma cantidad de métodos, ¿verdad? ¿O me estoy equivocando? –

El objetivo no es "salvarte" de burlarse de más objetos. El punto es que la prueba intenta decirte que hay un concepto faltante, por eso es tan complicado. –

A mí me suena como el código no comprobable, que es un olor :-(

Yo recomendaría leer http://misko.hevery.com/code-reviewers-guide/ El autor es el entrenador responsable de Google enseñanza. desarrolladores en el área de prueba. En el artículo muestra cómo puede escribir código comprobable e inestable.

Lectura recomendada: Código de limpieza (Robert C. Martin) - enfoque principal en cómo escribir limpio (que corresponde a prueba) código. Trabajando eficazmente con código heredado (Michael Feather): muestra formas de obtener código no probado e inestable bajo control.

Fuente

2009-06-29 06:30:41 jens

y si no le importa un breve descanso comercial ... http://www.mockobjects.com/book –

Podría ser un signo de alto acoplamiento, lo que a su vez implica la necesidad de reducir las dependencias (lo que mejorará el diseño y la capacidad de prueba). Como una guía aproximada, un objeto debe tener entre 4 y 6 colaboradores como máximo. Cualquier cosa por encima de eso activaría mis alarmas.

How are Mocks meant to be used?

Fuente

2009-06-29 06:42:25 Gishu

Respuesta

Cuestiones relacionadas