Модульное тестирование модели данных: связанные объекты - PullRequest
3 голосов
/ 25 сентября 2011

Я новичок в модульном тестировании и TDD, и после прочтения некоторых статей я решил запустить TDD в своем небольшом проекте.это простое бронирование билетов в театр, в котором используется шаблон NHibernate и Repository.Я решил сначала написать несколько тестов для моей модели данных, поэтому я начал с простых операций CRUD над объектами.Первой проблемой, с которой я столкнулся, были лица, имеющие отношения многие-к-одному.например, у меня есть объект Show , который имеет связь "многие к одному" с объектом Director (каждое шоу имеет директора), поэтому для тестирования метода Show.Create у меня былосоздать объект «Директор», чтобы сначала назначить ему «Показать».

Поскольку модульное тестирование настоятельно не поощряет написание зависимых тестов, как я могу преодолеть эту проблему без зависимости от таких связанных объектов?

Ответы [ 2 ]

3 голосов
/ 26 сентября 2011

Мне кажется, это помогает думать о TDD как о том, как написать пример того, как что-то использовать, и почему поведение интересно.

Так, например, в вашем приложении вы можете иметь такое поведение:

Шоу связывается с режиссером при его создании.

Однако это не очень интересно. Почему это ценно? Где это используется? Если вы можете показать какой-то аспект поведения, в котором это важно, это более интересно.

Репутация шоу начинается с репутации режиссера.

Затем вы можете написать пример такого поведения:

Given a director with a reputation of 75%
When he creates a new show
Then the show should start with a reputation of 75%.

Это было бы более интересным поведением. Мы действительно можем создать шоу с такой репутацией, не используя Hibernate. Я иногда помещаю подобные примеры в комментарии. (Я использую это в качестве примера, поскольку я понятия не имею, почему создание шоу с режиссером важно для вас!)

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

Мой опыт показывает, что можно создавать реальные доменные объекты (Show, Director и т. Д.), А не издеваться над ними. Однако, если у вас есть какие-то сложные расчеты - например, возможно, есть сложности с вычислением репутации Шоу, если оно было в течение нескольких ночей - тогда вы можете ввести макет, чтобы помочь с этим, и ваше поведение изменится соответственно:

A show uses the reputation rules for its reputation

// Given the reputation rules
(mock out the reputation)

// When a show is created with a director
(create the show)

// And it's shown for 3 nights with varying reviews
(associate the reviews with the show)

// Then it should use the rules to calculate its reputation
(verify that when you get the reputation, the show asks the mock for help).

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

0 голосов
/ 25 сентября 2011

Просто создайте интерфейс IDirector, который вы поместите в конструктор Show Entity.Таким образом, вы можете создать макетную (тестовую) реализацию вашего директора перед назначением на шоу.Просто реализуйте интерфейс IDirector самостоятельно с некоторыми фиктивными данными или с помощью Rhino Mocks.См. http://haacked.com/archive/2006/06/23/usingrhinomockstounittesteventsoninterfaces.aspx для примера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...