Unidad de Pruebas en .Net con Endeca objetos

Question

La mayor parte o la totalidad de los objetos de Endeca tienen constructores internos. Estoy trabajando en un proyecto bien que carece de gran cobertura de la prueba alrededor de la API de Endeca, ¿hay buenas estrategias a la unidad de prueba las interacciones con Endeca?

Hasta el momento lo mejor que tenemos es una especie de adapter de un hombre pobre: ??

public class DimValue : IDimValue
{
    public DimValue(Dimension dim, DimVal dimValue)
    {
        Dimension = dim;
        Value = dimValue;
    }

    public virtual bool IsNavigable()
    {
        return Value.IsNavigable();
    }

    public virtual long Id()
    {
        return Value.Id;
    }

    // and so on...
}

A continuación, puede burlarse de nuestro propio tipo, DimValue. ¿Es esta la mejor manera de mantener su API como comprobable como puede ser? O hay otro método que se prefiere para esto?

Answer 1

Si usted está tratando de probar su uso de la API, entonces, recomendaría el enfoque que usted ha mencionado.

Es un buen objetivo de diseño para estar escribiendo su aplicación construida sobre sus propias abstracciones, no de otra persona. La capa adaptador le da la oportunidad de traducir la API en un lenguaje de dominio de sus desarrolladores son más cómodo y le da la libertad de tecnologías de cambio más adelante, si el producto que está utilizando está a la altura de alguna manera.

ReSharper tenía una gran característica para crear clases contenedoras. Crear una clase, agregar un miembro que es el tipo que desee para envolver .. entonces activan la generan los delegados refactorización. Pick 'todos los públicos' y hay que ir .. una clase envueltos.

Sólo exponga el subconjunto de la funcionalidad que en realidad se está utilizando. En su código de envolver, proporcionar interfaces para que pueda burlarse.

Si está probando API de Endeca como una forma de suite de regresión para que pueda aceptar más fácilmente nuevo lanzamiento de su API, entonces yo simplemente pruebas de escritura a un nivel más 'aceptación'; el ejercicio de la API que le dan. Pero de nuevo, sólo probar las maneras en realidad se está usando su API.

Me haría el enfoque anterior, sin embargo ...

Typemock le permitirá clases simuladas sin las interfaces, por lo que puede permitir otro enfoque.

Espero que esto ayude.

Answer 2

La mayoría de las clases Endeca son concretos por lo que es difícil de hacer las pruebas unitarias, en nuestro último proyecto definido debemos a nosotros mismos un nivel abstracto, es exactamente lo que era una capa de fachada entre nuestro propio código y Endeca API, por ejemplo, IEndecaQuery. Con ese nivel de abstracción de lo que podíamos hacer una prueba rápida y sin ningún acceso real Endeca, sabes abrir una conexión Endeca le costará varios segundos cada vez. Fue mucho trabajo para poner en práctica todos los objetos falsos Endeca necesarias. Nuestra aplicación fue un sitio de comercio electrónico y utiliza Endeca para todos los listados de productos, funciones de búsqueda.