Какой отличный способ провести интеграционное тестирование? - PullRequest
24 голосов
/ 11 мая 2009

Мы написали наш собственный комплект интеграционных тестов, где мы можем написать ряд «операций» или тестов, таких как «GenerateOrders». У нас есть ряд параметров, которые мы можем использовать для настройки тестов (например, количество заказов). Затем мы записываем вторую операцию, чтобы подтвердить, что тест пройден / не пройден (то есть есть (nt) заказов).

Инструмент используется для

  • Интеграционное тестирование
  • Генерация данных
  • Сквозное тестирование (путем смешивания и сопоставления нескольких тестов)

Кажется, что это работает хорошо, однако для поддержки и написания новых тестов требуется опыт разработки. Наша команда по тестированию хотела бы принять участие, у которых мало опыта разработки на C #.

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

Вопросы заключаются в следующем:

  • Как вы проводите интеграционное тестирование?
  • Какой инструмент вы используете для этого (FitNess ?, Custom ?, NUnit)?

Я с нетерпением жду предложений / комментариев от людей.

Заранее спасибо,

David

Ответы [ 3 ]

12 голосов
/ 14 мая 2009

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

В обоих случаях есть несколько инструментов:

Я работал над проектами, в которых успешно использовались Сахи или Селен для AFT веб-приложений, белый для AFT для .NET WPF или приложений winforms, swtBot для AFT клиентских приложений Eclipse Rich и frankenstein для AFT Java-приложений Swing.

Fitnesse полезен для тестов уровня обслуживания / API или для тестов, которые работают чуть ниже пользовательского интерфейса. Когда все сделано правильно, у него есть преимущество в том, что у него есть читабельные для бизнеса тесты, то есть не разработчики могут читать и понимать тесты. Такие инструменты, как NUnit, менее полезны для этой цели. SOAPUI особенно подходит для тестирования веб-служб SOAP.

Факторы, которые следует учитывать:

  • Продолжительность : Можете ли вы допустить 8-часовой тестовый прогон?
  • Хрупкость : AFT могут быть довольно хрупкими по отношению к развивающемуся приложению (например, могут изменяться идентификаторы и позиции виджетов). Требуются адекватные навыки и усилия, чтобы не жестко программировать меняющиеся детали.
  • Верность : Насколько близко вы хотите быть к реальному миру? например Возможно, вам придется смоделировать взаимодействие с платежным шлюзом, если только провайдер не предоставит вам тестовую среду, которую вы можете использовать в своих тестах.

Некоторые нюансы зафиксированы здесь .

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

2 голосов
/ 13 июня 2009

Вы можете попробовать инфраструктуру Concordion для написания пользовательских приемочных тестов в файлах HTML. Требуется подход в стиле BDD. Существует также .Net порт

1 голос
/ 14 мая 2009

Это еще не бета, но StoryTeller выглядит многообещающе:

...