Подтвердить что ты не робот

Является ли Google макет хорошей издевательской структурой?

Я новичок в тестировании модулей в своей компании, и мне нужно выбрать издевательскую структуру для использования. Раньше я никогда не использовал насмешливую структуру. Мы уже выбрали Google Test, поэтому использование Google Mock было бы неплохо. Однако мои первоначальные впечатления после просмотра учебника Google Mock:

  • Необходимость повторного объявления каждого метода в классном классе с помощью макроса MOCK_METHODn кажется ненужным и, похоже, противоречит принципу DRY.
  • Их совпадения (например, "_" в EXPECT_CALL (черепаха, вперед (_));) и порядок соответствия кажется почти слишком мощным. Например, было бы легко сказать то, что вы не имеете в виду, и пропускать ошибки таким образом.

У меня высокая уверенность в разработчиках Google и низкая уверенность в моей собственной способности судить насмешливые рамки, никогда не используя их раньше. Поэтому мой вопрос: Являются ли эти действительные проблемы?

Или нет лучшего способа определить макет-объект, а совпадающие интуитивно понятны на практике? Я был бы признателен за ответы от тех, кто раньше использовал Google Mock, и сравнение с другими платформами С++ было бы полезно.

4b9b3361

ОТВЕТЫ

Ответ 1

Я использую его часто.

Это тривиально делать относительно простые вещи и делать очень сложные вещи - это в значительной степени то, что я хочу от фреймворка.

Самая сложная часть написания пользовательских совпадений (и других вещей) с помощью Google mocks - это не Google mocks, это ошибки шаблона С++... они почти невозможно разобрать. Я часто пишу сложные выражения путем постепенного создания рабочего выражения из нескольких менее сложных выражений. Таким образом, ошибки шаблона легче определить.

Я не видел лучшего варианта для С++ mocking, и Google покрывает много земли, поэтому я бы предложил вам сделать снимок.

WRT принцип СУХОЙ, я согласен, что объявление издевающихся методов является неудачным, но без размышлений я не уверен, что С++ повезло бы иначе. Я почти уверен, есть ли способ, googlemock будет его использовать;)

BTW: cookbook googlemock является хорошей ссылкой.

Ответ 2

Fake-It - простая фальшивая среда для С++. FakeIt использует последние возможности С++ 11 для создания выразительного (но очень простого) API. С FakeIt нет необходимости в повторном объявлении методов или создании производного класса для каждого макета. Вот как вы Fake-It:

struct SomeInterface {
  virtual int foo(int) = 0;
};

// That all you have to do to create a mock.
Mock<SomeInterface> mock; 

// Stub method mock.foo(any argument) to return 1.
When(Method(mock,foo)).Return(1);

// Fetch the SomeInterface instance from the mock.
SomeInterface &i = mock.get();

// Will print "1"
cout << i.foo(10);

Есть много возможностей для изучения. Идем дальше и попробуйте.

Ответ 3

Отказ от ответственности: я написал HippoMocks.

Я могу порекомендовать взглянуть на другие издевательские рамки; есть класс, который не заставит вас повториться. Они также устраняют новый синтаксис для сопоставления, делая ваш код более похожим на С++ в сочетании с английским. Попробуйте!

http://www.assembla.com/wiki/show/hippomocks

Ответ 4

Я использую googletest + googlemock профессионально в течение нескольких лет, и мне это определенно нравится. Одна вещь, о которой не говорили другие, заключается в том, что если вы уже готовы использовать googletest, то имеет смысл использовать googlemock. Они довольно хорошо интегрированы и имеют одинаковый стиль и философию дизайна, что приятно.

Например, googlemock предоставляет макросы ASSERT_THAT(), которые являются супер-полезными и хорошо сосуществуют с утверждениями googletests.

Я бы предупредил вас о злоупотреблении полномочиями googlemock. Это может быть очень заманчиво писать очень сложные и мощные матчи, которые в конечном итоге становятся совершенно нечитаемыми. Вам просто нужно быть дисциплинированным при его использовании.

Некоторые другие мысли:

  • Googlemock может иметь несколько крутую кривую обучения; тонкости матчей и ожидания не так прямолинейны, как вы могли бы надеяться.
  • Забота о нарушении DRY действительна; это раздражает, когда нужно вручную определять макеты, когда кажется, что они могут быть легко сгенерированы автоматически. Для команд довольно часто писать свои собственные генераторы кода, которые автоматически определяют googlemocks для своих интерфейсов.