Wykorzystanie IoC do testów jednostkowych

Jak kontener Ioc może być używany do testów jednostkowych?

IoC wymusi paradygmaty programowania, które ułatwią Testowanie jednostek w izolacji (np. przy użyciu mocks): użycie interfejsów, brak new (), brak singletonów...

Ale używanie kontenera IoC do testowania nie jest tak naprawdę wymogiem, zapewni tylko pewne udogodnienia, np. Wtrysk moków, ale można to zrobić ręcznie.

Czy warto zarządzać mockami w ogromnym rozwiązaniu (ponad 50 projektów) za pomocą MKOl?

Nie jestem pewien, co masz na myśli, zarządzając mockami za pomocą IoC. W każdym razie kontenery IoC mogą Zwykle robić więcej niż tylko wstrzykiwanie moków, jeśli chodzi o testowanie. A jeśli masz przyzwoitą obsługę IDE, która umożliwia refaktoryzację, dlaczego jej nie użyć?

Jakieś doświadczenie?

Tak, w przypadku ogromnego rozwiązania potrzebujesz bardziej niż kiedykolwiek rozwiązania nie podatnego na błędy i niekorzystnego na refaktoryzację (np. poprzez bezpieczny kontener IoC lub dobrą obsługę IDE).

Często używam kontenera IoC w moich testach. Oczywiście, nie są to "testy jednostkowe" w czystym sensie. IMO są bardziej BDDish i ułatwiają refaktoryzację. Testy są po to, aby dać ci pewność refactor. Źle napisane testy mogą być jak wlewanie cementu do kodu.

Rozważ co następuje:

[TestFixture]
public class ImageGalleryFixture : ContainerWiredFixture
{
    [Test]
    public void Should_save_image()
    {
        container.ConfigureMockFor<IFileRepository>()
            .Setup(r => r.Create(It.IsAny<IFile>()))
            .Verifiable();

        AddToGallery(new RequestWithRealFile());

        container.VerifyMockFor<IFileRepository>();
    }

    private void AddToGallery(AddBusinessImage request)
    {
        container.Resolve<BusinessPublisher>().Consume(request);
    }
}

Jest kilka rzeczy, które dzieją się podczas dodawania obrazu do galerii. Obraz jest zmieniany, generowana jest miniatura, a pliki są przechowywane na AmazonS3. Za pomocą kontener mogę łatwiej wyizolować tylko zachowanie, które chcę przetestować, co w tym przypadku jest utrzymującą się częścią.

Przy użyciu tej techniki przydatne jest automatyczne rozszerzenie kontenera: http://www.agileatwork.com/auto-mocking-unity-container-extension/

Używanie kontenerów z możliwością rozwiązywania niezarejestrowanych / uknown usług, takich jak SimpleInjector, DryIoc (jego kopalnia) może zwracać mocki dla jeszcze nie zaimplementowanych interfejsów.

Co oznacza, że można rozpocząć rozwój od pierwszej prostej implementacji i jej wyśmiewanych zależności, a w miarę postępów zastąpić je rzeczywistymi.