Repository generico per testare le migliori pratiche?

Question

Repository generico per testare le migliori pratiche?

#1 da (3 voti)

3

Come posso testare unitamente il mio repository generico?

Codice test unità:

[TestClass]
public class UnitTestLanguage
{
    private IUnityContainer _unityContainer;
    private IUnitOfWork _uow;
    private IGenericRepository<Language> _languageRepository;

    [TestInitialize]
    public void TestInitialize()
    {
        _unityContainer = new UnityContainer();
        _uow = _unityContainer.Resolve<UnitOfWork>();
        _languageRepository = _uow.GetRepository<Language>();
    }

    [TestCleanup]
    public void TestCleanup()
    {
        _uow = null;
        _unityContainer = null;
        _languageRepository = null;
    }


    [TestMethod]
    public void TestMethodInsertLanguage()
    {
        var newLanguage = new Language { Name = "test_language" };
        _languageRepository.Insert(newLanguage);
        var insertedRowCount = _uow.SaveChanges();

        var insertedLanguage = _languageRepository.Find(newLanguage.Id);
        _languageRepository.Delete(newLanguage);
        var deletedRowCount = _uow.SaveChanges();

        Assert.AreEqual(insertedLanguage.Name, newLanguage.Name);
        Assert.AreEqual(1, insertedRowCount);
        Assert.AreEqual(1, deletedRowCount);
    }
}

Uso qualcosa come sopra. Ma non so che questo è il modo corretto di testare il repository. Non riesco a trovare tutorial / articoli utili. Come dovrebbero essere i test unitari con le operazioni CRUD del repository generico?

unit-testing repository-pattern c#

posta AliRıza Adıyahşi 24.09.2013 - 08:44

fonte

1 risposta

Leggi altre domande sui tag unit-testing repository-pattern c#

Primo passo nell'analisi di un sistema proposto [duplicato] Python multithreading e utilizzo di processori moderni - qual è il rovescio della medaglia?

score 3 · Accepted Answer

A parte il suggerimento di Luc di testare una funzionalità per test (metodo), suggerirei di non usare l'unità per impostare l'unità sotto test. Strettamente parlando, questo non è più un test unitario, perché mette alla prova sia il tuo repository che la configurazione dell'unità.

Per ora potrebbe non essere un problema, ma può facilmente diventare uno in futuro. Si consideri, ad esempio, la situazione in cui qualcuno estende il proprio repository di lingue con alcune funzionalità di ricerca online. La rispettiva interfaccia di richiesta verrebbe probabilmente recuperata mediante DI. Di conseguenza, i test potrebbero improvvisamente iniziare a fallire a caso, a causa di timeout di connessione occasionali.

Dalla mia esperienza preferisco essere severo sulle dipendenze nei test unitari, cioè ogni input viene sostituito manualmente da un rispettivo simulacro. Questo è l'unico modo per assicurarti che un errore di test riguardi effettivamente qualche problema con l'unità (o le aspettative che i tuoi test esprimono).