Pregunta

Esta es una pregunta difícil porque no muchas personas usan Pex y lunares o así que creo que (a pesar de que Pex es un producto realmente bueno - mucho mejor que cualquier otra herramienta de prueba de unidad)

Tengo un datos proyecto que tiene un modelo muy simple con una sola entidad (DBItem). También he escrito un DBRepository dentro de este proyecto, que manipula este modelo EF. Repositorio tiene un método llamado GetItems() que devuelve una lista de los elementos de la capa de negocio (BLItem) y es similar a esto (ejemplo simplificado):

public IList<BLItem> GetItems()
{
    using (var ctx = new EFContext("name=MyWebConfigConnectionName"))
    {
        DateTime limit = DateTime.Today.AddDays(-10);
        IList<DBItem> result = ctx.Items.Where(i => i.Changed > limit).ToList();
        return result.ConvertAll(i => i.ToBusinessObject());
    }
}

Así que ahora me gustaría crear algunas pruebas unitarias para este método en particular. Estoy usando Pex y Moles . Creé mis lunares y talones para mi contexto del objeto EF.

Me gustaría escribir pruebas unitarias parametrizado (I saber en primer lugar que he escrito mi código de producción, pero tenía que, desde que estoy probando Pex y lunares) que las pruebas de que este método devuelve lista válida de artículos.

Esta es mi clase de prueba:

[PexClass]
public class RepoTest
{
    [PexMethod]
    public void GetItemsTest(ObjectSet<DBItem> items)
    {
        MEFContext.ConstructorString = (@this, name) => {
             var mole = new SEFContext();
        };

        DBRepository repo = new DBRepository();
        IList<BLItem> result = repo.GetItems();

        IList<DBItem> manual = items.Where(i => i.Changed > DateTime.Today.AddDays(-10));

        if (result.Count != manual.Count)
        {
            throw new Exception();
        }
    }
}

Luego ejecutar Pex Exploraciones para esta unidad de prueba parametrizado en particular, pero me da un error límites Ruta superado . Pex comienza esta prueba proporcionando null a este método de ensayo (así items = null). Este es el código que se está ejecutando Pex:

[Test]
[PexGeneratedBy(typeof(RepoTest))]
[Ignore("the test state was: path bounds exceeded")]
public void DBRepository_GetTasks22301()
{
    this.GetItemsTest((ObjectSet<DBItem>)null);
}

Este fue el comentario adicional proporcionada por Pex:

El caso de prueba corrió demasiado tiempo para estas entradas y Pex detuvo el análisis. Por favor aviso: El método Oblivious.Data.Test.Repositories.TaskRepositoryTest.b__0 fue llamado 50 veces; Por favor, compruebe que el código no se ha quedado atascado en un bucle o bucle infinito. De lo contrario, haga clic en 'Set MaxStack = 200', y ejecute Pex de nuevo.

atributo Update [PexMethod (MaxStack = 200)]

Pregunta

estoy haciendo esto de la manera correcta o no? ¿Debo usar EFContext talón en su lugar? ¿Tengo que añadir atributos adicionales para el método de ensayo de modo Moles anfitrión va a correr (no estoy seguro de que lo hace ahora). Me estoy quedando solo Pex y lunares. Sin VS prueba o nUnit o cualquier otra cosa.

supongo que probablemente debería establecer un límite a Pex cuántos elementos se debe prever este método de ensayo en particular.

¿Fue útil?

Solución

Los lunares no está diseñado para poner a prueba las partes de la aplicación que tienen dependencias externas (por ejemplo, acceso a archivos, acceso a la red, acceso a bases de datos, etc.). En cambio, los lunares le permite burlas de estas partes de su aplicación por lo que de esa manera se puede hacer verdadera unidad de pruebas en las partes que no tienen dependencias externas.

Así que creo que sólo debe burlarse de sus objetos y consultas de EF, por ejemplo, mediante la creación de listas en memoria y tener métodos de consulta de retorno de datos falsos a las listas basadas en cualquier criterio es relevante.

Otros consejos

Soy simplemente llegar a enfrentarse con PEX también ... mis problemas me rodearon querer usarlo con moq;)

de todos modos ...

Tengo algunos métodos similares a la que tienen el mismo problema. Cuando he aumentado al máximo se fueron. Es de suponer que pex estaba convencido de que había explorado suficientemente las ramas. Tengo procedimientos en los que he tenido que aumentar el tiempo de espera en la validación del contrato código también.

Una cosa que probablemente debería ser doign aunque está pasando en todos los objetos dependientes como parámetros ... es decir, no haga una instancia de la cesión temporal en el método, pero pasarlo en.

Un problema general que se tiene es que está crear instancias de objetos grandes en su método. Yo hago lo mismo en mis clases DAL, pero entonces no soy tryign a ellos prueba de la unidad de forma aislada. Construyo conjuntos de datos y usar esto para probar mi código de acceso a datos en contra.

Yo uso PEX en mi lógica de negocio y los objetos.

Si volviera a tratar de probar mi código DAL identificación para utilizar COI para pasar el DataContext en los métodos - que luego se harán las pruebas posible, ya que puede burlarse del contexto de datos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top