Come utilizzare “Pex e Moles” biblioteca con Entity Framework?

Question

Questa è una dura perché non troppe persone usano Pex & Moles o almeno così credo (anche se Pex è davvero un grande prodotto - molto meglio di qualsiasi altro strumento di test di unità)

Ho un Dati progetto che ha un modello molto semplice, con un solo soggetto (DBItem). Ho anche scritto un DBRepository nell'ambito di questo progetto, che manipola questo modello EF. Repository ha un metodo chiamato GetItems() che restituisce un elenco di elementi di livello aziendale (BLItem) e simile a questa (esempio semplificato):

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());
    }
}

Così ora vorrei creare alcuni test di unità per questo particolare metodo. Sto utilizzando Pex & Moles . Ho creato il mio talpe e stub per il mio contesto dell'oggetto EF.

Vorrei scrivere unit test parametrizzato (So che ho scritto il mio primo codice di produzione, ma ho dovuto, dal momento che sto testando Pex & Moles) che i test che questo metodo restituisce elenco valido di elementi.

Questa è la mia classe di test:

[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();
        }
    }
}

Poi corro Pex Explorations per questo particolare test di unità parametrizzato, ma ottengo un errore limiti Percorso superato . Pex inizia questo test fornendo null Al metodo (così items = null). Questo è il codice, che Pex è in esecuzione:

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

Questa è stata commento aggiuntivo fornito da Pex:

  

Il caso test è stato eseguito troppo lungo per questi ingressi, e Pex fermato l'analisi. Si prega di preavviso: Il metodo Oblivious.Data.Test.Repositories.TaskRepositoryTest.b__0 è stato chiamato 50 volte; Si prega di verificare che il codice non viene bloccato in un ciclo o di ricorsione infinita. In caso contrario, fare clic su 'Set MaxStack = 200', ed eseguire nuovamente Pex.

     

Aggiornamento attributo [PexMethod (MaxStack = 200)]

Domanda

sto facendo questo il modo corretto o no? Dovrei usare EFContext stub invece? Devo aggiungere altri attributi al metodo di prova in modo Moles ospite sarà in esecuzione (non sono sicuro che lo fa ora). Io corro solo Pex & Moles. No VS test o NUnit o qualsiasi altra cosa.

Credo che probabilmente devo impostare qualche limite alla Pex quanti elementi dovrebbe fornire per questo particolare metodo di prova.

Answer 1

Le talpe non è progettato per testare le parti dell'applicazione che hanno dipendenze esterne (ad esempio accesso ai file, accesso alla rete, di accesso al database, ecc). Invece, Moles permette di deridere queste parti della vostra applicazione in modo che modo si può fare vera unità di test sulle parti che non hanno dipendenze esterne.

Quindi penso che si dovrebbe solo prendere in giro i vostri oggetti EF e le query, per esempio, con la creazione di elenchi in memoria e con metodi di query restituiscono dati falsi da tali elenchi in base a qualsiasi criterio è rilevante.

Answer 2

io sono solo alle prese con PEX anche ... i miei problemi circondati me che vogliono utilizzarlo con moq;)

in ogni caso ...

Ho alcuni metodi simili al vostro che hanno lo stesso problema. Quando ho aumentato il massimo se ne andarono. Presumibilmente pex era soddisfatto di aver sufficientemente esplorato i rami. Ho metodi in cui ho dovuto aumentare il timeout sulla convalida del contratto di codice anche.

Una cosa che si dovrebbe probabilmente essere doign anche se sta passando in tutti gli oggetti dipendenti come parametri ... cioè Non istanziare il repo nel metodo, ma passarlo in.

Un problema generale che si ha è che si sta Instantiating grandi oggetti nel metodo. Faccio lo stesso nelle mie classi DAL, ma allora io non sono tryign per unità di prova di loro in isolamento. Costruisco up set di dati e lo uso per testare il mio codice di accesso ai dati contro.

Io uso PEX sulla mia logica di business e gli oggetti.

Se dovessi provare e testare il mio codice DAL id devono utilizzare CIO per passare il DataContext nei metodi - che sarebbe poi fare il test possibile, come si può deridere il contesto dati.

Answer 3

Si dovrebbe usare Entity Framework Repository Pattern: http://www.codeproject.com/ KB / database / ImplRepositoryPatternEF.aspx