Тестирование бизнес-приложений .NET?
Мне было интересно, есть ли у кого-нибудь здесь опыт модульного тестирования LOB-приложений (обычно CRUD).
Я пробовал использовать встроенные инструменты модульного тестирования в Visual Studio, но мне было трудно запускать тесты, которые попадают в базу данных. Поскольку данные меняются, и в сочетании с тем фактом, что я плохо понимаю, что делаю, кажется очень трудным получить ожидаемые результаты и опровергнуть их. Также я даже слышал, что вы не должны запускать модульные тесты для баз данных ... но как все остальные выполняют модульные тесты на CRUD LOB-программном обеспечении?
Я так много слышал о TDD и непрерывной интеграции с тестированием, но мне кажется, что если я даже не могу создавать модульные тесты для начала, я не могу использовать эти методологии. Это означает, что такой продукт, как Блокнот, будет легко создавать модульные тесты для ... у вас есть определенное количество функций, и эти функции всегда должны давать один и тот же результат. Но с бизнес-приложениями у вас есть такие вещи, как заказы на продажу, которые можно создавать, удалять или изменять в вашей среде тестирования.
Любое понимание будет оценено!
Ответы 4
Как правило, с CRUD вам понадобится либо имитировать, либо использовать контейнер IOC для вашего уровня доступа к данным, чтобы вы не всегда попадали в базу данных и «изменяемые данные».
С модульными тестами вы всегда ожидаете одинаковых значений, поэтому подключение к базе данных обычно вызывает проблемы.
Ознакомьтесь с RhinoMocks или Inversion Of Control Containers.
Я создаю базовую базу данных и использую dbUnit для ее экспорта в набор файлов XML. Первый проход теста - это очистка и заполнение тестовой базы данных базовым показателем. После этого вы сможете утверждать, что модульные тесты соответствуют ожидаемым значениям.
Автоматизированное тестирование - это широкая категория, которая содержит две меньшие категории: модульное тестирование и интеграционное тестирование.
Модульное тестирование - это практика выявления мельчайших единиц вашей программы и написания процедур, тестирующих их изолированно друг от друга. Когда самые маленькие элементы вашей программы тесно связаны друг с другом, может быть трудно тестировать их изолированно друг от друга. В этом случае есть методы и инструменты, которые могут вам помочь (имитирующие и имитирующие фреймворки). Чтобы эффективно проводить модульное тестирование, ваша кодовая база должна быть написана определенным образом, таким образом, который поддерживает модульное тестирование - самые маленькие элементы вашей программы не должны быть связаны вместе. Большинство программ не строятся с учетом этого принципа, поэтому их сложно тестировать. Модульное тестирование там, где вы можете, и помните об этом принципе для любого нового кода, который вы пишете, чтобы вы всегда могли выполнить модульное тестирование своего нового кода.
Интеграционное тестирование - это практика выявления функций, которые являются большими единицами вашей программы, интегрирующими множество более мелких единиц, и написания процедур, тестирующих их изолированно от других больших единиц вашей программы. Например, процедура проверки того, что ваш уровень сохраняемости правильно сохраняет объекты в постоянное хранилище и правильно извлекает объекты из постоянного хранилища, является интеграционным тестом, поскольку он проверяет как ваш уровень сохраняемости, так и конвейер TCP / IP, конфигурацию базы данных, базу данных. схему, данные, уже находящиеся в базе данных, и взаимодействие между данными, уже находящимися в базе данных, и тем, что делает ваш код. Обязательно проведите интеграционное тестирование в дополнение к модульному тестированию.
Кроме того, создайте отдельную базу данных исключительно для целей автоматизированных интеграционных тестов. Старайтесь не запускать автоматические интеграционные тесты в производственной базе данных или базе данных для разработки, потому что вы просто столкнетесь с проблемами.
Я наткнулся на ту же проблему, у вас не так много вариантов ...
- откат после каждого теста (с использованием xtUnit для NUnit или атрибута отката MbUnit). это отлично работает для типичных модульных тестов операций CRUD.
- используйте стратегию восстановления из резервной копии до и после теста. Это сделает выполнение модульного теста долгим. Однако это поддерживается MbUnit (2.X атрибуты отсутствуют в магистрали 3.x)
- создать / удалить базу данных с помощью сценариев sql.
Самым большим преимуществом последних двух вариантов является то, что вы можете использовать их при выполнении так называемых интеграционных тестов (например, при автоматизации пользовательского интерфейса, когда вам необходимо поддерживать изменения базы данных на каком-то другом уровне (физическом сервере)).
Я использую последний в сочетании с Ватин для веб-приложений. Для WPF и Win32 взгляните на белый, он выглядит многообещающим.