JBehave , или с более традиционными инструментами, такими как JUnit, чтобы упростить написание автоматических приемочных тестов и предоставить более богатую и полезную живую документацию. В серии из двух статей мы рассмотрим тесную одно- и двустороннюю интеграцию, которую Thucydides предлагает с JIRA.
В остальной части этой статьи предполагается, что вы знакомы с Фукидидом. Для ознакомления с руководством Thucydides ознакомьтесь с документацией Thucydides или этой статьей для быстрого ознакомления.
Начало работы с интеграцией Thucydides / JIRA
JIRA — это популярная система отслеживания проблем, которая также часто используется для гибкого управления проектами и требованиями. Многие команды, использующие JIRA, хранят свои требования в электронном виде в виде карточек историй и эпопей в JIRA.
Предположим, мы внедряем приложение для часто летающих пассажиров авиакомпании. Идея заключается в том, что путешественники будут зарабатывать баллы, когда они летят с нашей авиакомпанией, в зависимости от расстояния, которое они летят. Путешественники начинают со статуса «Бронза» и могут получить лучший статус, совершая полеты чаще. Путешественники с более высоким статусом часто летающих пассажиров получают такие преимущества, как доступ в салон, приоритетная посадка на борт и т. Д. Одна из карт истории для этой функции может выглядеть следующим образом:
Эта история содержит описание, следующее за одним из часто используемых форматов для описания пользовательских историй («как … я хочу … так и есть»). Он также содержит настраиваемое поле «Критерии принятия», в котором мы можем записать краткое описание «определения выполненного» для этой истории.
Эти истории могут быть сгруппированы в эпосы и помещены в спринты для планирования проекта, как показано на гибкой доске JIRA, показанной здесь:
Как показано в карточке истории, каждая из этих историй имеет набор критериев приемлемости, которые мы можем встроить в более подробные сценарии на основе конкретных примеров. Затем мы можем автоматизировать эти сценарии, используя инструмент BDD, такой как JBehave.
История на рисунке 1 описывает, сколько очков участники должны заработать, чтобы получить каждый уровень статуса. Сценарий JBehave для карты истории, показанной ранее, может выглядеть следующим образом:
Frequent Flyer status is calculated based on points Meta: @issue FH-17 Scenario: New members should start out as Bronze members Given Jill Smith is not a Frequent Flyer member When she registers on the Frequent Flyer program Then she should have a status of Bronze Scenario: Members should get status updates based on status points earned Given a member has a status of <initialStatus> And he has <initialStatusPoints> status points When he earns <extraPoints> extra status points Then he should have a status of <finalStatus> Examples: | initialStatus | initialStatusPoints | extraPoints | finalStatus | notes | | Bronze | 0 | 300 | Silver | 300 points for Silver | | Silver | 0 | 700 | Gold | 700 points for Gold | | Gold | 0 | 1500 | Platinum | 1500 points for Platinum |
Thucydides позволяет связывать истории JBehave или тесты JUnit с картой JIRA, используя метатег @issue (показан выше), или эквивалентную аннотацию @Issue в JUnit. На самом базовом уровне это создаст ссылки на соответствующие карты JIRA в ваших отчетах о тестировании, как показано здесь:
Чтобы это работало, Thucydides должен знать, где находится ваш сервер JIRA. Самый простой способ сделать это — определить следующие свойства в файле с именем thucydides.properties в корневом каталоге вашего проекта:
jira.url=https://myserver.atlassian.net jira.project=FH jira.username=jirauser jira.password=t0psecret
You can also set these properties up in your Maven pom.xml file or pass them in as system properties.
Thucydides also supports two-way integration with JIRA. You can also get Thucydides to update the JIRA issue with a comment pointing to the corresponding test result.
Feature Coverage
But test results only report part of the picture. If you are using JIRA to store your stories and epics, you can use these to keep track of progress. But how do you know what automated acceptance tests have been implemented for your stories and epics, and, equally importantly, how do you know which stories or epics have no automated acceptance tests? In agile terms, a story cannot be declared «done» until the automated acceptance tests pass. Furthermore, we need to be confident not only that the tests exist, but they test the right requirements, and that they test them sufficiently well.
We call this idea of measuring the number (and quality) of the acceptance tests for each of the features we want to build «feature coverage». Thucydides can provide feature coverage reporting in addition to the more conventional test results. If you are using JIRA, you will need to add thucydides-jira-requirements-provider to the dependencies section of your pom.xml file:
<dependencies>
...
<dependency>
<groupId>net.thucydides.plugins.jira</groupId>
<artifactId>thucydides-jira-requirements-provider</artifactId>
<version>0.9.260</version>
</dependency>
</dependencies>
(The actual version number might be different for you — always take a look at Maven Central to know what the latest version is).
You will also need to add this dependency to the Thucydides reporting plugin configuration:
<build>
...
<plugins>
...
<plugin>
<groupId>net.thucydides.maven.plugins</groupId>
<artifactId>maven-thucydides-plugin</artifactId>
<version>0.9.257</version>
<executions>
<execution>
<id>thucydides-reports</id>
<phase>post-integration-test</phase>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>net.thucydides.plugins.jira</groupId>
<artifactId>thucydides-jira-requirements-provider</artifactId>
<version>0.9.260</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
If you click on an epic, you can see the stories defined for the epic, including an indicator (in the «Coverage» column) of how well each story has been tested.
From here, you may want to drill down into the details about a given story, including what acceptance tests have been defined for this story, and whether they ran successfully:
Both JIRA and the JIRA-Thucydides integration are quite flexible. We saw earlier that we had configured a custom «Acceptance Criteria» field in our JIRA stories. We have displayed this custom field in the report shown above by including it in the thucydides.properties file, like this:
jira.custom.field.1=AcceptanceCriteria
Thuydides reads the narrative text appearing in this report («As a frequent flyer…») from the Description field of the corresponding JIRA card. We can override this behavior and get Thucydides to read this value from a different custom field using the jira.custom.narrative.field property. For example, some teams use a custom field called «User Story» to store the narrative text, instead of the Description field. We could get Thucydides to use this field as follows:
jira.custom.narrative.field=UserStory
Conclusion
Thucydides has rich and flexible one and two-way integration with JIRA. Not only can you link back to JIRA story cards from your acceptance test reports and display information about stories from JIRA in the test reports, you can also read the requirements structure from JIRA, and report on which features have been tested, and which have not.
In the next article in this series, we will learn how to insert links to the Thucydides reports into the JIRA issues, and how to actively update the state of the JIRA cards based on the outcomes of your tests.
Want to learn more? Be sure to check out the Thucydides web site, the Thucydides Blog, or join the Thucydides Google Users Group to join the discussion with other Thucydides users.
Wakaleo Consulting, the company behind Thucydides, also runs regular courses in Australia, London and Europe on related topics such as Agile Requirements Gathering, Behaviour Driven Development, Test Driven Development, and Automated Acceptance Testing.