TDD и насмешливый - PullRequest
Новая
       10

TDD и насмешливый

3 голосов
/ 06 апреля 2011

Прежде всего, я должен сказать, что я новичок в насмешках. Так что, возможно, я упускаю точку.

Я также только начинаю привыкать к подходу TDD.

Итак, в моем реальном проекте я работаю над классом на бизнес-уровне, пока уровень данных еще не развернут. Я подумал, что сейчас самое время начать насмехаться. Я использую Rhino Mocks, но я столкнулся с проблемой необходимости знать детали реализации класса перед написанием самого класса.

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

простой пример: 

public void CreateAandB(bool arg1, bool arg2) {
    if(arg1)
        daoA.Create();
    else throw new exception;
    if(arg2)
        daoB.Create();
    else throw new exception;
}

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

Я что-то упустил?

Ответы [ 2 ]

4 голосов
/ 06 апреля 2011

У вас есть 2 варианта.Если метод должен привести к некоторым изменениям в вашем классе, вы можете вместо этого протестировать результаты вашего метода.Поэтому вы можете вызвать CreateAandB(true,false), а затем вызвать другой метод, чтобы проверить, была ли создана правильная вещь.В этой ситуации ваши фиктивные объекты, вероятно, будут заглушками, которые просто предоставляют некоторые данные.

Если doaA и doaB - это объекты, которые внедряются в ваш класс и фактически создают данные в БД или аналогичные, чтовы не можете проверить результаты теста, затем вы хотите проверить взаимодействие с ними, и в этом случае вы создаете макеты и устанавливаете ожидания, затем вызываете метод и проверяете, что ожидания удовлетворены.В этой ситуации ваши фиктивные объекты будут имитировать и проверять ожидаемое поведение.

Да, вы тестируете детали реализации, но вы тестируете детали , если ваш метод правильно использует свои зависимости, то, что вы хотите проверить, а не как он использует их, то есть детали, которые вас на самом деле не интересуют.

РЕДАКТИРОВАТЬ 

IDao daoA = MockRepository.GenerateMock<IDao>(); //create mock
daoA.Expect(dao=>dao.Create); //set expectation

...

daoA.VerifyExpectations(); //check that the Create method was called

вы можете гарантировать, что ожидания произойдут в определенном порядке, но не использую синтаксис AAA, я полагаю (источник из 2009 , возможно, изменился с тех пор, EDIT см. здесь для опции, которая может работать ), но этоКажется, кто-то разработал подход, который мог бы разрешить это здесь .Я никогда не использовал это и не могу проверить это.

Что касается необходимости знать, какой метод был вызван первым, чтобы вы могли проверить исключение, у вас есть несколько вариантов:

  • Получите другое сообщение в вашем исключении и проверьте, чтобы определить, какое исключение было вызвано.
  • Ожидайте вызов daoA в дополнение к ожиданию исключения.Если вы не получите вызов daoA, то тест не пройден, поскольку исключение должно быть первым.
2 голосов
/ 06 апреля 2011

Часто вам просто нужны поддельные предметы, а не издевательства.Поддельные объекты предназначены для проверки взаимодействия компонентов, и часто этого можно избежать, напрямую запрашивая состояние SUT.Наиболее практическое использование mock для тестирования взаимодействия с какой-либо внешней системой (БД, файловая система, веб-сервис и т. Д.), А для других целей вы должны иметь возможность напрямую запрашивать состояние системы.

...