TDD и 3-х уровневая архитектура

Question

Мне нужно реализовать TDD в 3-х уровневой архитектуре.

Примеры в книгах и блогах имеют смысл при тестировании вхождений charater в строке или тестировании функции Pop в стеке. Но когда речь идет о N-Tier Application, где у нас есть пользовательский интерфейс, бизнес-уровень и уровень данных Уровень данных по очереди вызывает требуемые хранимые процедуры и получает данные.

Концепция TDD заключается в том, чтобы проводить тесты изолированно, а это значит, что мы должны имитировать или подделывать данные.

Но мои сомнения по поводу этой методологии заключаются в том, что следует проверить TDD. Я понял, что он проверяет, возвращает ли, например, функция GetCustomer ожидаемый результат.

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

А также как реализовать TDD для операций CRUD?

Любые примеры будут очень полезны для полного понимания концепции TDD

Привет

Answer 1

Прежде всего я бы сказал, что читайте немного больше о Mocks (вы имитируете роли ... не данные / объекты).

W.r.t. к вашему примеру, я бы

1. Модульные тесты для класса представления / модели представления (ваш уровень пользовательского интерфейса). Здесь я бы посмеялся над бизнес-уровнем / ролью, например. убедитесь, что классы представления вызывают правильные методы на службах, когда я делаю X
2. Модульные тесты по классам домена (бизнес-уровень). Здесь я высмеиваю слой доступа к данным .. например убедитесь, что GetCustomer () вызывается, когда я делаю X
3. Интеграционные тесты, которые проверяют, что MyRepository.GetCustomer () действительно правильно выбирает данные из «реальной» тестовой БД. Поэтому в идеале ошибка в вашем StoredProc должна быть поймана и помечена здесь.

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

TDD может использоваться для всего вышеперечисленного.

Answer 2

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

Например, если Employee является бизнес-классом и вызывает EmployeeSerializer.GetAll (), мне нужно только проверить Employee.GetAll. Если EmployeeSerializer () не возвращает правильные данные, я буду знать это. Если EmployeeSerializer выдает неожиданное исключение, я буду знать это. Если EmployeeSerializer не выдает правильные исключения, я буду знать это.

Не кодируйте свои тесты для проверки деталей реализации. Кодируйте их, чтобы проверить бизнес-правила. Это означает, что вы тестируете бизнес-объекты. Чтобы облегчить эту работу, я помечаю свои объекты доступа к данным как ВНУТРЕННИЕ, поэтому не могу проверить их вне бизнес-контекста, в котором они предназначены для использования.

Но это я, и я уверен, что у других разные мнения.

ADDENDUM: Храните бизнес-правила как можно дальше от хранимых процедур. Также настройте известные тесты, используя [Setup] и [TearDown]. Помните, что тест проверяет целое бизнес-правило. Вы можете выполнять как можно больше работы по настройке теста, если тест выполняется изолированно, и вы можете восстановить его исходное состояние после завершения теста. Поэтому, если вы хотите вставить данные, убедитесь, что у вас есть метод бизнес-класса, который это делает. То же самое для обновления, удаления и выбора.