Тестирование бизнес-приложений (LOB) .NET?

Question

Мне было интересно, есть ли у кого-нибудь здесь опыт модульного тестирования LOB-приложений (обычно CRUD).

Я пробовал встроенные средства модульного тестирования в Visual Studio, но мне было трудно запускать тесты, работающие с базой данных. Поскольку данные меняются и в сочетании с тем фактом, что я слабо представляю, что я делаю, кажется очень сложным получить ожидаемые результаты и утверждать их. Кроме того, я даже слышал, что вам не следует запускать модульные тесты для баз данных ... но как все остальные выполняют модульные тесты для программного обеспечения CRUD LOB?

Я так много слышу о TDD и непрерывной интеграции с тестированием, но кажется, что если я не могу даже создать модульные тесты для начала, я действительно не могу использовать эти методологии. Это делает то, что такой продукт, как Блокнот, будет легко создавать модульные тесты для ... у вас есть определенное количество функций, и эти функции всегда должны давать один и тот же результат. Но с LOB-приложениями у вас есть такие вещи, как Заказы на продажу, которые можно создавать, удалять или изменять в вашей среде тестирования.

Любое понимание будет оценено!

Answer 1

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

Answer 2

Автоматическое тестирование - это широкая категория, которая содержит две меньшие категории: модульное тестирование и интеграционное тестирование.

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

Интеграционное тестирование - это практика выявления функций, которые являются большими единицами вашей программы, объединяющими множество более мелких блоков, и написание процедур, тестирующих их отдельно от других больших блоков вашей программы. Например, процедура, проверяющая, что ваш уровень персистентности правильно сохраняет объекты в постоянное хранилище и правильно извлекает объекты из постоянного хранилища, является интеграционным тестом, поскольку она проверяет как ваш уровень персистентности, так и конвейер TCP / IP, конфигурацию базы данных, базу данных схема, данные, уже находящиеся в базе данных, и взаимодействие между данными, уже находящимися в базе данных, и тем, что делает ваш код. Обязательно проведите интеграционное тестирование, в дополнение к модульному тестированию.

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

Answer 3

Как правило, с CRUD вам потребуется либо Mock, либо использовать IOC-контейнер для слоя доступа к данным, чтобы вы не всегда обращались к базе данных и «изменяемым данным».

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

Проверьте RhinoMocks или инверсию контейнеров управления.

Answer 4

Я наткнулся на ту же проблему, у вас не так много вариантов ...

• откат после каждого теста (с использованием xtUnit для NUnit или атрибута отката MbUnit). это нормально работает для типовых юнит-тестов операций CRUD.
• используйте стратегию восстановления резервной копии перед тестированием. Это продлит выполнение модульного теста. Однако это поддерживается MbUnit (атрибуты 2.X отсутствуют в транке 3.x)
• создание / удаление БД с использованием сценариев sql.

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

Я использую последний в сочетании с Watin для веб-приложений. Для WPF и Win32 взгляните на Белый , это выглядит многообещающе.