Тестирование по API Economy

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

Соединители

Наличие общего API для создания интеграций является важным шагом в создании фабрики. Tasktop Sync использует Mylyn Tasks в качестве API для интеграции. Mylyn Tasks — это фантастический API и инфраструктура, изначально разработанная для интеграции IDE, позволяющая разработчикам вносить артефакты ALM (задачи, ошибки, запросы на изменение, требования и т. Д.) В свою среду IDE. В основе этого API лежит общая модель данных для артефактов ALM и API для выполнения основных операций CRUD и поиска. Мы называем реализации этого API «соединителями». У нас много разъемов; один для каждого из Atlassian JIRA, Microsoft TFS, IBM RTC, IBM RRC, HP Quality Center и HP ALM, CA Clarity и т. д.

Рисунок 1: типичный коннектор Mylyn, связанный с API

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

Нам нужно знать, что каждый коннектор правильно реализует API. Нам нужно знать возможности коннектора и веб-службы, а также их различия для каждой версии веб-службы и их изменения по мере выпуска новых версий веб-службы. Нам нужно знать, что работает, а что нет и почему; это недостаток реализации коннектора или ограничение веб-сервиса? Это приводит нас к разъему TCK.

Разъем TCK

В один из наших инновационных дней Ship-It один из наших инженеров создал прототип набора общих тестов, которые можно настроить для работы с любым разъемом. Почему бы не применить концепцию TCK к разъемам? Бенджамин окрестил свое творение Соединителем TCK, и название застряло. Соединитель TCK должен иметь тесты, которые гарантируют, что каждый соединитель реализован правильно, и проверяет возможности каждой реализации.

Рисунок 2: Разъем TCK

Типы тестов, которые были добавлены в Connector TCK, варьировались от самых базовых (например, соединение может быть установлено с репозиторием) до более подробных (например, прикрепление файла к артефакту может быть правильно создано и получено с помощью символов, не входящих в ASCII, в имя файла вложения). Прелесть Connector TCK в том, что он может использоваться для измерения качества и возможностей каждого соединителя в равной степени. Он может быть настроен на запуск соединителя для нескольких версий репозитория, фактически мы тестируем столько версий, сколько считаем необходимым для обеспечения правильного поведения для любой поддерживаемой версии конечной точки интеграции.

Рисунок 3: тестирование коннектора с несколькими версиями репозитория

Наличие соединителя TCK — это здорово, но мы упустили важный вопрос: какие тесты должны быть в нем? Единственный способ узнать наверняка — это иметь определенный контракт, спецификацию.

Спецификация

Для некоторых разработчиков программного обеспечения требования не гламурны, не интересны и даже не настолько интересны. Когда мы сидим перед клавиатурой, первое, что мы хотим сделать, — это начать разрабатывать код. Это аналогично созданию дома без чертежей. Конечно, это весело — но дом, в конце концов, не будет тем, что мы хотим. Спецификация интеграции («спецификация») — это план, который объясняет желаемое поведение интеграций. Спецификация принимает следующую форму:

• User Stories (US) — истории, написанные с точки зрения пользователя, которые определяют функциональность интеграции
• Технические пользовательские истории (TUS) — истории, написанные с технологической точки зрения, которые сопоставляются с API коннектора
• Критерии приемки (AC) — критерии, которые должны быть выполнены, чтобы техническая пользовательская история считалась завершенной

Вот пример из спецификации:

US-2: клиент Connector может установить соединение с хранилищем

• TUS-2.1: клиент коннектора может установить соединение с сервером репозитория с учетом URL, учетных данных и других необходимых параметров соединения
  
  • AC-2.1.1: клиент коннектора может проверять URL, учетные данные и другие необходимые параметры соединения и получать отзывы об успешном соединении
  • AC-2.1.2: клиент Connector получает значимую обратную связь для неверного или отсутствующего URL
  • AC-2.1.3: клиент соединителя получает значимую обратную связь для неверных или отсутствующих учетных данных
  • AC-2.1.4: клиент коннектора…
• TUS-2.2: клиент коннектора может…

Нормальная разработка программного обеспечения часто включает в себя создание функций для спецификации (или без спецификации) и дальнейшее развитие. В нашем случае, когда мы строим много интеграций, которые, по сути, делают одно и то же, мы получаем большую отдачу от спецификации. TUS и AC в спецификации применимы к каждой реализации коннектора, которых много. Поэтому мы ценим спецификацию с неким почтением, которое необычно для разработчиков программного обеспечения.

Потянув его вместе

Волшебство в этом процессе действительно обнаруживается, когда мы собираем его вместе. Используя JUnit и его мощную TestRuleконцепцию, мы можем связать наши тесты с AC из спецификации, используя простую аннотацию:

@Retention (RUNTIME)
@Target (метод)
public @interface Validates {
	/ **
	 * Предоставляет идентификаторы критериев приемки.
	 * /
	Строковое значение();
}

Вот пример используемой аннотации:

	@Тест
	@Validates ( "2.1.2")
	public void testMissingUrl () {
		// Попробуй это
	}

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

Рисунок 4: Отчет о соответствии TCK

Что будет дальше?

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

О Дэвид Грин

Дэвид Грин — вице-президент по архитектуре компании Tasktop Technologies. До Tasktop Дэвид был одним из основателей MAKE Technologies, где занимал должности технического директора, вице-президента по технологиям и главного архитектора инструментов. В MAKE Дэвид впервые применил модельно-ориентированный подход к устаревшей модернизации на платформе Eclipse, интегрируя бизнес-требования, генерацию семантического кода и преобразование данных. Дэвид является коммиттером Eclipse и создателем Mylyn WikiText, платформы и инструментов для интеграции форматирования вики в платформу Eclipse. Дэвид хорошо известен своим читаемым блогом Green’s Opinion, приложениями для iPhone и Android и выступлениями на конференциях, таких как JavaOne и EclipseCon.

• почта

|


• Web

|


• Больше сообщений (4)