Зависимости в приемочном тестировании - PullRequest
2 голосов
/ 07 октября 2010

Я и его коллега спорим. Мы находимся в потрясающем унаследованном проекте и постепенно добавляем приемочные тесты. Он считает, что мы должны выполнять работу в графическом интерфейсе пользователя, а затем использовать низкоуровневую библиотеку для непосредственного запроса к базе данных, чтобы получить «сквозной» тест, как он его выразил.

Мы используем NHibernate, и я рекомендую использовать gui / watin, а затем эти объекты nhibernate для выполнения утверждений в приемочном тестировании. Ему не нравится зависимость NHibernate в тесте. Я утверждал, что у нас есть / должны быть интеграционные тесты с объектами NHibernate, чтобы убедиться, что они работают с БД так, как мы намереваемся, и в этом случае нет недостатка в использовании их в приемочном тесте для подтверждения правильности работы. Я также думаю, что его низкоуровневая зависимость от SQL сделает тесты хрупкими и дублирует бизнес-логику во многих случаях.

Интеграционное тестирование в нашем магазине в основном означает, что это отдельный компонент с зависимостью, например, fileRepository / FileSystem Domain-NhibernateObject / База данных. Приемочное тестирование означает вход через GUI. Единица означает, что все зависимости могут / могут быть смоделированы / заглушены, и у вас есть чистый тест в памяти, и только тестируемый метод фактически выполняет какую-либо реальную работу. Дайте мне знать, если моя защита выключена.

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

1 Ответ

2 голосов
/ 08 октября 2010

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

Привязка их к объектам NHibernate также не очень поможет, я боюсь!

Пользователи вашихСистема не будет использовать базу данных или NHibernate.Как они получают выгоду (или предоставляют выгоду другим заинтересованным сторонам)?Как они смогут сказать, что это работает хорошо?Если вы сможете зафиксировать , что в приемочных тестах, вы сможете изменить базовый код и данные, сохраняя при этом ценность вашего приложения.Если кто-то генерирует отчеты на основе данных, почему бы не сгенерировать те же отчеты и убедиться, что их содержание соответствует вашим ожиданиям?Если данные читаются другой системой, вы можете получить копию этой системы и посмотреть, что она выводит для ее пользователей?

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

Да, и провести интеграционные тесты, чтобы проверить, что ваши (N) привязки Hibernateхорошо это отличная идея.Спасли нас на пару проектов.

...