2013-12-11 2 views
2

Я пытаюсь понять, почему насмешка ведет себя таким образом (я использую NUnit с Moq). Скажем, у нас есть простой класс:Издевательские объекты с разными конструкторами

public class Package 
{ 
    public virtual int PackageId { get; set; } 

    public Package() 
     :this(-1) 
    { 
    } 

    public Package(int packageId) 
    { 
     PackageId = packageId; 
    } 
} 

И некоторые простые тесты для обсуждения:

[TestFixture] 
public class NUnitTrickyTest 
{ 
    private const int SamplePackageId = 10; 

    [Test] 
    public void TestPackageSetUp_WhenMockedWithDefaultConstructor_ExpectSamplePackageIdSet() 
    { 
     var samplePackage = new Mock<Package>(); 

     samplePackage.SetupProperty(x => x.PackageId, SamplePackageId); 

     Assert.AreEqual(SamplePackageId, samplePackage.Object.PackageId); 
    } 

    [Test] 
    public void TestPackageSetUp_WhenMockedWithParametrizedConstructor_ExpectSamplePackageIdSet() 
    { 
     var samplePackage = new Mock<Package>(SamplePackageId); 

     // samplePackage.SetupProperty(x => x.PackageId, SamplePackageId); 

     Assert.AreEqual(SamplePackageId, samplePackage.Object.PackageId); 
    } 
} 

Первый тест не пройден, как samplePackage.Object.PackageId возвращается -1, а не 10, как и ожидалось. Как я понимаю, издевается Package() вызывает параметризованный конструктор, который инициализирует свойство по умолчанию -1. Во втором тесте находим samplePackage.Object.PackageId, возвращающий 0.

Первое, что я не понимаю, почему было возвращено 0 (в отладке я увидел, что в конструкторе было передано 10, но свойство оставалось 0). Второй: если мы раскомментируем эту команду samplePackage.SetupProperty(x => x.PackageId, SamplePackageId) во втором тесте, она будет успешной. Итак, почему SetupProperty ведет себя так, как ожидалось, в этом случае (свойство возвращает 10), а не таким образом в первом тесте?

Не могли бы вы помочь? Это мой первый пост, так что не будьте серьезными :)

ответ

7

Все методы mockable (virtual) используют прокси-сервер по умолчанию, поэтому вы получаете значение по умолчанию (0) во втором тесте (прокси-сервер не является задавать). Вы можете обойти это, установив CallBase = true на ваш макет.

CallBase = true будет использовать стандартные реализации, если они доступны, вместо того, чтобы пытаться издеваться над всем.

Потребовалось некоторое время, чтобы выяснить причину первого отказа, и я считаю, что это связано с тем, что SetupProperty включает только отслеживание со значением по умолчанию, и поскольку вы переопределяете это значение по умолчанию в конструкторе, то это то, что используется. Если вы хотите заставить значение, то вам нужно использовать Setup(x=>x.PackageId).Returns(SamplePackageId) или SetupGet

+0

Хорошее примечание о настройке CallBase –

+0

Спасибо. Но первый не удался. PackageId инициализируется с помощью -1 конструктором и .SetupProperty не «переопределяет» его для изделенного объекта – Artem

+0

Я думал об этом чуть глубже и обновил свой ответ. Я должен был пойти в исходный код, чтобы действительно проверить, но я достаточно уверен в своем ответе –

Смежные вопросы