ОК, ваше приложение звучит громко! Я могу поделиться своим опытом в отношении приложения, которое мы недавно разработали; это был графический интерфейс, говорящий о веб-сервисах с сервером, который в свою очередь связывался с несколькими базами данных и другими веб-сервисами. Клиентская база составляла около 15 000 пользователей ... В любом случае - это много работы, независимо от того, как вы к ней подходите; плюс, это поможет вам не грызть ногти каждый раз, когда вы делаете релиз!
MVVM
В общем, я бы также порекомендовал шаблон MVVM и провел бы как можно больше испытаний без графического интерфейса. Тестирование GUI просто сложно! Мне нравится статья Джоша Смита на MSDN: « Приложения WPF с шаблоном проектирования Model-View-ViewModel » (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx)
Тестовые сценарии
Уловка с этим приложением заключалась в том, что у нас было много чего для тестирования, его внутренности постоянно двигались, и (как ни странно) не хватало людей, чтобы выполнить тестирование для каждой итерации.
Мое решение состояло в том, чтобы придумать специальный инструмент тестирования, который бы использовал существующие библиотеки. У нас был простой скрипт-движок, который считывал файл и выполнял команды. По сути, мы разработали DSL (http://en.wikipedia.org/wiki/Domain-specific_language) для тестирования нашего конкретного приложения. DSL включал в себя несколько простых команд для обозначения того, какое «окно» он тестировал, какие-либо конкретные «установочные» сигналы, а затем серия команд с последующими утверждениями. Выглядело это примерно так:
Test NewXyzItem
Setup Clear_items
Press Some_button
Enter_text_into Name Bobby Joe
(...)
Press Save
Assert_db_has_itemX SomeKey
Формат каждой строки
"command" "argument" [data]
Сценарии объединяются в группы каталогов, и «тестовый прогон» загружает их, анализирует и выполняет их. Создание журналов и отчетов на ходу полезно, я попался на крючке для создания скриншотов и т. Д., Которые пригодились. Если вы заинтересованы в реализации чего-то подобного и хотите руку, дайте мне знать .
Удобно было то, что мы могли вносить общие изменения в стратегию тестирования.
Написание сценариев становится довольно простым, что важно, потому что у вас получается много, много сценариев. Элементы управления обнаруживаются по имени, поэтому вы следуете соглашению (например, «Имя» может быть «NameTextBox» в коде или «Сохранить» может быть «SaveButton»).
На самом деле вы можете использовать NUnit и т. Д., Чтобы быть вашим тестовым бегуном.
ПРИМЕЧАНИЕ. - Просто запустите тесты в интерактивном режиме, получить тест GUI для работы с CI сложно и проблемно ...
Данные и тестирование
Одна важная вещь здесь - это то, что управление данными было огромной частью проблемы тестирования и не может быть пропущено. Наше «новое развертывание» также было очень долгим, но некоторые части были внешними, и мы не могли контролировать свежесть данных. То, как мы справились с очисткой, заключалось в предоставлении хуков через сценарии, которые позволяли нам легко удалять объекты перед тестами. Не оптимально, но редко возникало.
Библиотеки
Библиотека, которую вы можете найти наиболее полезной в " White " (http://white.codeplex.com/). Она может тестировать приложения Windows в целом - т.е. как WPF, так и WinForms. По сути, вы в конечном итоге кодируете такие вещи, как эта :
Button button = window.Get<Button>("SaveButton");
button.Click();
Если ваше приложение выполняет асинхронные вызовы, вам необходимо разработать стратегию, позволяющую организатору тестов знать, когда асинхронный вызов завершен, возможно, через строку состояния или что-то в этом роде. Зависит от того, как ты зацепишься ...
Опять же, много работы, но оно того стоит.
ПК: -)