Как вы тестируете свои бизнес-объекты?

Question

Я хочу внедрить автоматизированное тестирование с использованием инфраструктуры тестирования Microsoft в Visual Studio для моих проектов разработки программного обеспечения. Я создал несколько тестов, и в целом его довольно просто использовать.

Какие рекомендации для тестирования бизнес-объектов , в частности, тех, которые читают и записывают в базу данных.

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

Лучше ли использовать какой-то тип очистки после своего менталитета, то есть, если я тестирую метод AddUser, могу ли я добавить пользователя, проверить свои тесты, а затем удалить пользователя?

Проверяете ли вы каждый из методов CRUD в одном методе?

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

Я понимаю, что это довольно широкий вопрос ... просто искать какое-то направление ... предпринять шаги для ребенка.

Подробнее ...

Много хороших ответов! Я не уверен, что смогу осуществить фиктивную базу данных. Я использую CSLA в качестве основы для своих объектов. Требуется серьезный рефакторинг, чтобы сделать его тестируемым с фиктивными объектами. Я собираюсь разобраться в этом. Хотя, в какой-то момент, я do хочу проверить взаимодействие с базой данных ... при использовании фиктивной базы данных, где / когда вы действительно протестируете связь с базой данных?

Еще один вопрос ... лучше ли сохранять каждый метод испытаний независимым от других тестов?

Answer 1

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

Если вы не можете избежать объединения бизнес-правил и доступа к БД в один класс (возможно, это проблематичный дизайн, но иногда его трудно избежать), то вам придется тестировать БД.

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

Даже не думайте о попытке инициализировать БД один раз, а затем запустить все тесты на одни и те же данные. Один тест случайно изменит данные, и другие тесты таинственным образом не пройдут. Я сделал это и пожалел об этом ... Каждый тест действительно должен быть сам по себе.

Чтобы сделать все это, я настоятельно рекомендую какой-нибудь фреймворк для тестирования БД. Это поможет вам очистить базу данных, загрузить необходимые данные и сравнить запрос результаты к ожидаемым результатам. Я использую DBUnit (для Java), но есть много других для других языков.

Answer 2

Я бы порекомендовал реализовать ваши бизнес-объекты так, чтобы они не знали о базе данных. Используйте методы на уровне доступа к данным, которые могут правильно сохранять / извлекать бизнес-объекты в зависимости от их типа (т. Е. У него есть внутреннее сопоставление между таблицами и объектами, которым они соответствуют). При тестировании самого вашего бизнес-объекта вам вообще не нужно беспокоиться о базе данных. Просто создайте объект, возможно, используйте отражение, чтобы установить приватные поля, и проведите тест на объекте.

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

Answer 3

Более подробную информацию о TDD с CSLA можно найти в ответах на на этот вопрос . Особенно этот .

Также этот вопрос может быть интересным.

Answer 4

Использовать внедрение зависимости . Реализуйте ваши методы базы данных в интерфейсе. Затем напишите новую реализацию интерфейса с контрольными данными для проверки применимых сценариев.

Answer 5

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

Одним из решений, которое может вам помочь, является использование базы данных в памяти для ваших тестов. Например, SQLite позволяет вам создавать базы данных в оперативной памяти на лету, и когда вы располагаете ими, они исчезают. Это делает ваши тесты намного быстрее, и вам не нужно настраивать код очистки - в то время как вы фактически тестируете свой код SQL / db с помощью автоматических тестов.

Answer 6

Чтобы протестировать уровень доступа к БД, не следует запускать все тесты на одном и том же БД. Некоторые тесты могут не пройти, потому что они зависят от результатов другого теста. Так что это не то, что вы хотите. Фактически после каждого теста перед выполнением теста вы должны возвращать статус БД в исходное состояние.

В своей практике я сохраняю набор тестовых данных в XML и перед каждым тестом настраиваю данные в дБ с использованием XML. Таким образом, каждый тест выполняется с каким-либо набором данных.

Answer 7

Обычно я создаю BO, сохраняю его в db в настройке прибора, затем провожу тесты на различные операции вставки / обновления / выбора, затем в моем демонтаже удаляю объект из базы данных. Это делает вещи красивыми и чистыми, особенно когда задействовано множество ограничений, ваша тестовая база данных может очень быстро запутаться, если вы не удалите все, что создали в своих тестах.

Answer 8

(я знаю, что вы не используете Java, но приведенная ниже общая стратегия вообще не зависит от Java)

Я работаю над проектом Java, который использует много кода EJB3 / JPA. Я решил создать своего рода фиктивный контейнер, способный «развертывать» EJB-компоненты и использовать базу данных в памяти (HSQL) с менеджером сущностей hibernate.

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

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