Когда использовать модульное тестирование против поддельного в модульном тестировании C #?

Question

Может ли кто-нибудь придумать руководящие принципы, предлагающие идеальные сценарии выбора насмешек по сравнению с подделкой, то есть настройку основ вручную?

Я немного запутался в том, как подойти к этой ситуации.

Answer 1

Ну, у вас есть несколько вещей, которые вам нужно разобраться. У вас есть две основные вещи, которые вам нужно знать: номенклатура и лучшие практики.

Сначала я хочу дать вам отличный видео-ресурс от великого тестировщика, Роя Ошерова:

Обзоры юнит-тестирования Роя Ошерова

Он начинает с того, что говорит, что у него есть сделал несколько обзоров жгутов поставляется с несколькими открытыми исходными кодами проекты. Вы можете найти их здесь: http://weblogs.asp.net/rosherove/archive/tags/TestReview/default.aspx

Это в основном видеообзоры где он проводит вас через эти испытания запрягает и говорит, что хорошо и что плохого. Очень полезно.

У Роя тоже есть книга, которую я понимаю это очень хорошо.

Номенклатура

Этот подкаст поможет очень : http://www.hanselminutes.com/default.aspx?showID=187

Я перефразирую подкаст, хотя (что вступительное слово Hanselminutes ужасно):

В основном все, что вы делаете с структура изоляции (например, Moq, Rhino Mocks, Type Mock и т. Д.) Называется поддельный .

A fake - это объект, используемый во время тест на то, что код, который вы тестируете можете позвонить вместо производственного кода. Подделка используется, чтобы изолировать код, который вы пытаются проверить из других частей ваше заявление.

Существует (в основном) два вида подделок : заглушки и издевается .

A mock - это подделка, которую вы положили поместите так, чтобы код, который вы тестируете можете обратиться к нему, и вы утверждаете, что звонок был сделан с правильным параметры. Пример ниже просто это с помощью изоляции Moq основа:

[TestMethod]
public void CalculateTax_ValidTaxRate_DALCallIsCorrect()
{
    //Arrange
    Mock<ITaxRateDataAccess> taxDALMock = new Mock<ITaxRateDataAccess>();
    taxDALMock.Setup(taxDAL => taxDAL.GetTaxRateForZipCode("75001"))
                  .Returns(0.08).Verifiable();

    TaxCalculator calc = new TaxCalculator(taxDALMock.Object);

    //Act
    decimal result = calc.CalculateTax("75001", 100.00);

    //Assert
    taxDALMock.VerifyAll();
}

A заглушка почти такая же, как издеваться, кроме того, что вы положили его на место чтобы убедиться, что код, который вы тестируете возвращает согласованные данные из его позвонить (например, если ваш код звонит слой доступа к данным, заглушка будет вернуть поддельные данные), но вы не утверждать против самого окурка. Тот вы не хотите убедиться, что метод называется ваш поддельный доступ к данным слой - вы пытаетесь проверить что-то другое. Вы предоставляете заглушку чтобы получить метод, который вы пытаетесь тест для работы в изоляции.

Вот пример с заглушкой:

[TestMethod]
public void CalculateTax_ValidTaxRate_TaxValueIsCorrect()
{    
    //Arrange
    Mock<ITaxRateDataAccess> taxDALStub = new Mock<ITaxRateDataAccess>();
    taxDALStub.Setup(taxDAL => taxDAL.GetTaxRateForZipCode("75001"))
                  .Returns(0.08);

    TaxCalculator calc = new TaxCalculator(taxDALStub.Object); 

    //Act
    decimal result = calc.CalculateTax("75001", 100.00);

    //Assert
    Assert.AreEqual(result, 8.00);
}

Обратите внимание, что мы тестируем вывод метода, а не тот факт, что метод сделал вызов другой ресурс.

Moq действительно не создает API Различие между макетом и заглушкой (обратите внимание, что оба были объявлены Mock<T>), но использование здесь важно при определении типа.

Надеюсь, это поможет вам разобраться.

Answer 2

По крайней мере, 5 различных типов тестовых двойников: манекены, заглушки, шутки, шпионы и подделки. Хороший обзор на http://code.google.com/testing/TotT-2008-06-12.pdf, и они также классифицируются на http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html

Answer 3

The Little Mocker , от Боба Мартина, очень хорошее чтение по теме.

[...] давным-давно очень умные люди написали статью, которая ввела и определила термин «ложный объект». Многие другие люди прочитали его и начали использовать этот термин. Другие люди, которые не читали газету, услышали термин и начали использовать его в более широком смысле. Они даже превратили слово в глагол. Они говорили: «Давайте высмеем этот объект» или «У нас много дел для насмешек».

В статье объясняются различия между издевательствами, подделками, шпионами и окурками.

Answer 4

Вы хотите протестировать кусок кода, верно, скажем, метод. Ваш метод загружает файл с URL-адреса http, а затем сохраняет файл на диске, а затем рассылает по почте, что файл находится на диске. Все эти три действия, конечно, являются классами обслуживания, которые вызываются вашими методами, потому что тогда их легко смоделировать. Если вы не издеваетесь над этим, ваш тест будет загружать материал, получать доступ к диску и отправлять сообщение по электронной почте каждый раз, когда вы будете запускать этот тест. Тогда вы не просто тестируете код в методе, вы также тестируете код, который загружает, записывает на диск и отправляет почту. Теперь, если вы над ними издеваетесь, вы тестируете только код методов. Также вы можете имитировать сбой загрузки, например, чтобы убедиться, что код вашего метода работает правильно.

Теперь, что касается подделки, я обычно фальсифицирую классы, которые просто содержат значения и не имеют большой логики. Если вы отправляете объект, содержащий некоторые значения, которые изменились в методе, вы можете прочитать его в тесте, чтобы убедиться, что метод делает правильные вещи.

Конечно, правила могут (а иногда и должны) немного сгибаться, но общий способ мышления - это тестирование вашего кода и только вашего кода.