Как правильно сделать TDD? Когда я пишу тесты для уровней, которые глубже моего уровня бизнес-логики (то есть DAL)? - PullRequest
1 голос
/ 14 мая 2009

Я все еще не уверен, как лучше использовать Mocks при разработке извне (т.е. сначала написать тест, который имитирует требования заказчика)

Предположим, что требование моего клиента: "Клиент может отменить свой заказ".

Я могу написать тест для этого - Test_Customer_Can_Cancel_Her_Order.

Используя TDD, я затем пишу бизнес-класс и моделирую уровень доступа к данным (или любой уровень, который «глубже», чем уровень моей бизнес-логики). Фантастика, мои тесты пройдены, и я тестирую только бизнес-уровень, а не какие-либо уровни под ним.

Теперь мне интересно ... когда я углублюсь и начну писать и тестировать слой доступа к данным? Сразу после теста верхнего уровня? Только когда я пишу интеграционный тест? Может это не важно? Пока это будет сделано в какой-то момент?

Просто интересно ...

Ответы [ 3 ]

5 голосов
/ 14 мая 2009

Это сложный вопрос. Некоторые люди считают, что тестировать «закрытый» код можно, а некоторые - нет. Это, безусловно, проще, поскольку вам не нужно выполнять сложные настройки для воспроизведения состояния приложения, которое позволяет вам протестировать небольшую функцию, которую вы хотите добавить (вы можете протестировать эту функцию напрямую). Раньше я был среди этих людей, но теперь я бы сказал, что лучше всего тестировать общедоступные API (создавать тесты и настройки, которые делают и видят только то, что пользователь может делать и видеть). Причина этого заключается в том, что если вы тестируете только публичный API, вы получаете неограниченный потенциал ре-факторинга. Если вы тестируете закрытый код, вам придется изменить свои тесты, если вы решите повторно фактор (что сделает вас менее склонным к «беспощадному рефакторингу», что приведет к плохому коду).

Однако я должен сказать, что тестирование только общедоступных API do приводит к более сложным средам тестирования.

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

О, если для приложений с графическим интерфейсом это немного сложнее, так как вы действительно не хотите переходить к точке, где вы проверяете щелчки мышью и читаете пиксели. Это просто глупо. Если вы используете (и должны использовать) систему MVC, остановитесь на уровне контроллера.

1 голос
/ 14 мая 2009

Я всегда пишу тесты для тестирования уровня DAO, который не тестирует бизнес-логику, но я считаю, что важно тестировать функции CRUD. Это доставило мне много хлопот, потому что если моя база данных по какой-то причине повреждена, мои тесты имеют высокую вероятность провала. Чтобы предотвратить сбой этих типов тестов DAO, сначала выполните тестирование в непроизводственной базе данных. Затем для каждого теста CRUD / DAO I

  1. найти объекты, которые могли остаться после предыдущего теста, и если они существуют, я их удаляю.
  2. Я создаю объекты, которые хочу проверить
  3. Я обновляю объекты, которые хочу протестировать
  4. Я очищаю или удаляю созданные мной объекты.

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

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

1 голос
/ 14 мая 2009

Используйте интеграционные тесты для тестирования запросов и других данных.

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