unit-testing
Test Doubles

Uwagi

Użycie kodu pośredniczącego w celu dostarczenia konserwowanych odpowiedzi

Odcinek jest lekkim testem podwójnym, który zapewnia konserwowane odpowiedzi, gdy wywoływane są metody. W przypadku, gdy testowana klasa opiera się na interfejsie lub klasie bazowej, do testowania zgodnego z interfejsem można zastosować alternatywną klasę „stub”.

Zakładając następujący interfejs,

public interface IRecordProvider {
    IEnumerable<Record> GetRecords();
}

Jeśli miałaby zostać przetestowana następująca metoda

public bool ProcessRecord(IRecordProvider provider)

Można zapisać klasę pośredniczącą implementującą interfejs, aby zwrócić znane dane testowanej metodzie.

public class RecordProviderStub : IRecordProvider
{
    public IEnumerable<Record> GetRecords()
    {
        return new List<Record> {
            new Record { Id = 1, Flag=false, Value="First" },
            new Record { Id = 2, Flag=true, Value="Second" },
            new Record { Id = 3, Flag=false, Value="Third" }
        };
    }
}

Tę implementację kodu pośredniczącego można następnie dostarczyć do testowanego systemu, aby wpłynąć na jego zachowanie.

var stub = new RecordProviderStub();
var processed = sut.ProcessRecord(stub);

Korzystanie ze szkieletu próbnego jako kodu pośredniczącego

Terminy Mock i Stub często mogą się mylić. Jedną z przyczyn tego jest to, że wiele frameworkowatych ram zapewnia również wsparcie dla tworzenia Stubów bez etapu weryfikacji związanego z Drwiną.

Zamiast pisać nową klasę do implementacji kodu pośredniczącego, jak w przykładzie „Korzystanie z kodu pośredniczącego w celu dostarczenia odpowiedzi w puszce”, można zamiast tego zastosować schematy próbne.

Za pomocą Moq:

var stub = new Mock<IRecordProvider>();
stub.Setup(provider => provider.GetRecords()).Returns(new List<Record> {
    new Record { Id = 1, Flag=false, Value="First" },
    new Record { Id = 2, Flag=true, Value="Second" },
    new Record { Id = 3, Flag=false, Value="Third" }
});

Osiąga to takie samo zachowanie jak kodowany ręcznie kod i może być dostarczony do testowanego systemu w podobny sposób:

var processed = sut.ProcessRecord(stub.Object);

Korzystanie z frameworka do sprawdzania poprawności zachowania

Próbki są stosowane, gdy konieczne jest sprawdzenie interakcji między testowanym systemem a testowanymi podwójnymi wartościami. Należy zachować ostrożność, aby uniknąć tworzenia zbyt kruchych testów, ale kpiny mogą być szczególnie przydatne, gdy metoda testowania polega po prostu na koordynowaniu innych wywołań.

Ten test weryfikuje, że gdy wywoływana jest testowana metoda ( ProcessRecord ), to metoda usługi ( UseValue ) jest wywoływana dla Record którym Flag==true . Aby to zrobić, konfiguruje kod pośredniczący z danymi w puszkach:

var stub = new Mock<IRecordProvider>();
stub.Setup(provider => provider.GetRecords()).Returns(new List<Record> {
    new Record { Id = 1, Flag=false, Value="First" },
    new Record { Id = 2, Flag=true, Value="Second" },
    new Record { Id = 3, Flag=false, Value="Third" }
});

Następnie ustawia próbną implementację interfejsu IService :

var mockService = new Mock<IService>();
mockService.Setup(service => service.UseValue(It.IsAny<string>())).Returns(true);

Są one następnie dostarczane do testowanego systemu i wywoływana jest metoda, która ma być testowana.

var sut = new SystemUnderTest(mockService.Object);

var processed = sut.ProcessRecord(stub.Object);

Próbkę można następnie przesłuchać, aby sprawdzić, czy zostało wykonane oczekiwane połączenie. W tym przypadku wywołanie UseValue z jednym parametrem „Second”, który jest wartością z rekordu, w którym Flag==true .

mockService.Verify(service => service.UseValue("Second"));