Skip to content

Archive for

31
Oct

Getting started with Thucydides – using the Thucydides Maven Archetypes


The easiest way to start a new Thucydides project is to use the Maven archetype. Two archetypes are currently available: one for using Thucydides with JUnit, and another if you also want to write your acceptance tests (or a part of them) using easyb.

From the command line, you can run mvn archetype:generate and then select the net.thucydides.thucydides-easyb-archetype archetype from the proposed list of archetypes. Or you can use your favorite IDE to generate a new Maven project using an archetype.

$ mvn archetype:generate
...
Define value for property 'groupId': : com.mycompany
Define value for property 'artifactId': : webtests
Define value for property 'version':  1.0-SNAPSHOT: :
Define value for property 'package':  com.mycompany: :
Confirm properties configuration:
groupId: com.mycompany
artifactId: webtests
version: 1.0-SNAPSHOT
package: com.mycompany
 Y: :
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:33.290s
[INFO] Finished at: Fri Oct 28 07:20:41 NZDT 2011
[INFO] Final Memory: 7M/81M
[INFO] ------------------------------------------------------------------------

This will create a simple Thucydides project, complete with a Page Object, a Step library and two test cases, one using JUnit, and one using easyb. Before going any further, take the project for a spin. First, add the net.thucydides.maven.plugins to your plugin groups in your settings.xml file :

<settings>
   <pluginGroups>
       <pluginGroup>net.thucydides.maven.plugins</pluginGroup>  
       ...
      </pluginGroups> 
  ...
</settings>

Now go into the generated project directory, run the tests and generate the reports:

$ mvn test thucydides:aggregate

This should run some web tests and generate a report in target/site/thucydides directory (open the index.html file). You should see a report like this one:

If you drill down into the individual test reports, you will see an illustrated narrative for each test:

Now for the details. the project directory structure is shown here:

+ src
   + main
      + java
         + com.mycompany.pages
            - HomePage.java   

   + test
      + java
         + com.mycompany.pages
            + requirements
               - Application.java
            + steps
               - EndUserSteps.java
            - SearchByKeywordStoryTest.java 

      + stories
         + com.wakaleo.webtests.wikipedia
            - SearchingForCats.story

This project is designed to provide a starting point for your Thucydides acceptance tests, and to illustrate some of the basic features. The tests come in two flavors: easyb and JUnit. easyb is a Groovy-based BDD (Behaviour Driven Development) library which works well for this kind of test. The sample easyb story can be found in the SearchingForCats.story file, and looks something like this:

	using "thucydides"

	thucydides.uses_default_base_url "http://www.wikipedia.com"
	thucydides.uses_steps_from EndUserSteps
	thucydides.tests_story SearchBySingleKeyword

	scenario "Searching for cats", {
	    given "the user is on the home page", {
	        end_user.is_on_the_wikipedia_home_page()
	    }
	    when "the end user searches for 'cats'", {
	        end_user.searches_by_keyword('cats')
	    }
	    then "they should see the corresponding article", {
	       end_user.should_see_article_with_title("Cat - Wikipedia, the free encyclopedia")
	    }
	}

A cursory glance at this story will show that it relates a user searching for entries on cats on Wikipedia. However only the “what” is expressed at this level – the details are hidden inside the test steps and, further down, inside page objects.

If you prefer pure Java tests, the JUnit equivalent can be found in the SearchByKeywordTest.java file:

@Story(SearchBySingleKeyword.class)
@RunWith(ThucydidesRunner.class)
public class SearchByKeywordStoryTest {

    @Managed(uniqueSession = true)
    public WebDriver webdriver;

    @ManagedPages(defaultUrl = "http://www.wikipedia.com")
    public Pages pages;

    @Steps
    public EndUserSteps endUser;

    @Test
    public void searching_by_keyword_cat_should_display_article_about_cats() {
        endUser.is_on_the_wikipedia_home_page();
        endUser.searches_by_keyword("cats");
        endUser.should_see_article_with_title("Cat - Wikipedia, the free encyclopedia");

    }

}

As you can see, this is a little more technical but still very high level.

The step libraries contain the implementation of each of the steps used in the high-level tests. For complex tests, these steps can in turn call other steps. The step library used in this example can be found in EndUserSteps.java:

public class EndUserSteps extends ScenarioSteps {

	public EndUserSteps(Pages pages) {
		super(pages);
	}

    @Step
    public void searches_by_keyword(String keyword) {
        enters(keyword);
        performs_search();
    }

	@Step
	public void enters(String keyword) {
        onHomePage().enter_keywords(keyword);
	}

    @Step
    public void performs_search() {
        onHomePage().starts_search();
    }

    private HomePage onHomePage() {
        return getPages().currentPageAt(HomePage.class);
    }

    @Step
	public void should_see_article_with_title(String title) {
        assertThat(onHomePage().getTitle(), is(title));
	}

    @Step
    public void is_on_the_wikipedia_home_page() {
        onHomePage().open();
    }
}

Page Objects are a way of encapsulating the implementation details about a particular page. Selenium 2 has particularly good support for page objects, and Thucydides leverages this. The sample page object can be found in the HomePage.java class:

	@DefaultUrl("http://www.wikipedia.org")
	public class HomePage extends PageObject {

		private WebElement searchInput;

		@FindBy(name="go")
		private WebElement searchButton;

		public HomePage(WebDriver driver) {
			super(driver);
		}

		public void enter_keywords(String keyword) {
			searchInput.sendKeys(keyword);
		}

	    public void starts_search() {
	        searchButton.click();
	    }
	}

The final piece in the puzzle is the Application.java class, which is a way of representing the structure of your requirements in Java form, so that your easyb and JUnit tests can be mapped back to the requirements they are testing:

	public class Application {
	    @Feature
	    public class Search {
	        public class SearchByKeyword {}
	        public class SearchByAnimalRelatedKeyword {}
	        public class SearchByFoodRelatedKeyword {}
	        public class SearchByMultipleKeywords {}
	        public class SearchForQuote{}
	    }

	    @Feature
	    public class Backend {
	        public class ProcessSales {}
	        public class ProcessSubscriptions {}
	    }

	    @Feature
	    public class Contribute {
	        public class AddNewArticle {}
	        public class EditExistingArticle {}
	    }
	}

This is what enables Thucydides to generate the aggregate reports about features and stories.

Advertisements
28
Oct

Thucydides Release 0.4.17 – Using Thucydides for non-web tests


A new version of Thucyides is out – version 0.4.17 – with some exiting new features. These include:

  • Support for using Thucydides for backend (i.e. non-web) tests
  • Thucydides archetypes
  • Improved easyb reporting
Let’s take a longer look at the first point. Although Thucydides is very much focused on web testing, not all acceptance tests are web tests, and Thucydides now lets you include non-web tests in your Acceptance Test reporting. Thucydides step libraries no longer need to extend the ScenarioSteps class. Indeed, if they do not deal with web tests, they have no reason to. (If they do use web tests, they can still extend the ScenarioSteps class, but they don’t have to – providing a constructor with a Pages parameter, or just having a field of type Pages, will suffice). For example, the following class could be used to model some backend steps:
public class BackendSteps {

    @Step
    public void accepts_a_sale_transaction() {...}

    @Step
    public void should_the_update_mainframe() {...}
}
You can then use these steps in your Thucydides tests. If your test doesn’t use Selenium 2, you don’t need to use the @Managed or @Pages annotations to define your driver and page object factories: you just need to declare the step library using the @Steps annotation:
@RunWith(ThucydidesRunner.class)
@Story(Application.Backend.ProcessSales.class)
public class WorkWithBackendTest {

    @Steps
    public BackendSteps backend;

    @Issue("#WIKI-1")
    @Test
    public void when_processing_a_sale_transation() {
        backend.accepts_a_sale_transaction();
        backend.should_the_update_mainframe();
    }
}
Alternatively, if you are using easyb, your test might look like this:

using "thucydides"

thucydides.uses_steps_from BackendSteps
thucydides.tests_story ProcessSales

thucydides.tests_issue "#WIKI-1"

scenario "Processing a sales transation", {
    when "the backend processes a sale", {
        backend.accepts_a_sale_transaction()
    }
    then "the mainframe should be updated", {
       backend.should_the_update_mainframe()
    }
}
These tests will now be executed as Thucydides tests and included in the reporting, both at the narrative level (though there are no screenshots of course), and in the overall aggregate reporting:
21
Oct

Thucydides Release 0.4.15 – 2-way JIRA integration


A new version of Thucydides is out – version 0.4.15 – with some exciting new features, updates and improvements. Thucydides is a library designed to make it easier to write automated acceptance criteria on top of WebDriver/Selenium 2 (see this article for a general introduction).

An overview of the highlights of this release are presented here:

  • Two-way integration with JIRA, including support for custom workflows
  • Better support for parallel testing in JUnit and easyb
  • This version uses Selenium 2.9.0
  • Easyb integration uses the latest version of easyb (1.4) from Maven Central (no messy custom repository configuration required)

In the rest of this article, we will concentrate how you can integrate JIRA with your automated acceptance tests using Thucydides.

When you are using Thucydides with JUnit or easyb, tests or scenarios can implement acceptance criteria for particular user stories. A common strategy for organizations using JIRA is to represent story cards, and/or the associated acceptance criteria, as JIRA issues.

To set up JIRA integration with Thucydides, you need to add the thucydides-jira-plugin to your Maven dependencies. The dependencies you will need (including the normal Thucydides ones) are listed here:

    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.8.2</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-all</artifactId>
        <version>1.1</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>net.thucydides</groupId>
        <artifactId>thucydides-junit</artifactId>
        <version>0.4.15</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>net.thucydides.easyb</groupId>
        <artifactId>thucydides-easyb-plugin</artifactId>
        <version>0.4.15</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>net.thucydides.plugins.jira</groupId>
        <artifactId>thucydides-jira-plugin</artifactId>
        <version>0.5.4</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <version>1.8.2</version>
    </dependency>         
    ...

Note that the JIRA workflow integration needs Groovy 1.8 or higher to work properly.

You will also need an slf4j implementation, e.g. ‘slf4j-log4j12’ (if you are using Log4j) or ‘logback-classic’ (if you are using LogBack) (see here for more details). If you’re stuck, just add slf4j-simple:

    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-simple</artifactId>
        <version>1.6.1</version>
    </dependency>

In Thucydides, you can refer to a JIRA issue by placing a reference to the corresponding JIRA issue number either in the name of the test (using the @Title annotation, for example), or, more simply, by using the @Issue or @Issues annotation as shown here:

    @RunWith(ThucydidesRunner.class)
    public class SearchByKeywordStoryTest {

        @Managed(uniqueSession = true)
        public WebDriver webdriver;

        @ManagedPages(defaultUrl = "http://www.wikipedia.com")
        public Pages pages;

        @Steps
        public EndUserSteps endUser;

        @Issue("#WIKI-1")
        @Test
        public void searching_by_unambiguious_keyword_should_display_the_corresponding_article() {
            endUser.is_on_the_wikipedia_home_page();
            endUser.looks_up_cats();
            endUser.should_see_article_with_title("Cat - Wikipedia, the free encyclopedia");

        }
    }

In this example, the test will be associated with issue WIKI-1.

Alternatively, you may want to associate an issue (such as a story card) with all of the stories in a test case by placing the @Issue (or @Issues) annotation at the class level:

 
        @RunWith(ThucydidesRunner.class)
        @Issue("#WIKI-1")
        public class SearchByKeywordStoryTest {

            @Managed(uniqueSession = true)
            public WebDriver webdriver;
            
            @ManagedPages(defaultUrl = "http://www.wikipedia.com")
            public Pages pages;

            @Steps
            public EndUserSteps endUser;

            @Test
            public void searching_by_unambiguious_keyword_should_display_the_corresponding_article() {
                endUser.is_on_the_wikipedia_home_page();
                endUser.looks_up_cats();
                endUser.should_see_article_with_title("Cat - Wikipedia, the free encyclopedia");

            }
        }

Thucydides can use these annotations to integrate with the issues in JIRA. The most simple JIRA integration involves adding links to the corresponding JIRA issues in the Thucydides reports. To activate this, you simply need to provide the *jira.url* command line option. You do however need to pass this option to JUnit using the maven-surefire-plugin, as shown here:

 
  <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.10</version>
            <configuration>
                <argLine>-Xmx1024m</argLine>
                <systemPropertyVariables>                              
                    <jira.url>http://jira.acme.com</jira.url>                               
                </systemPropertyVariables>     
            </configuration>
        </plugin>
        ...

For tighter, round-trip integration you can also use thucydides-jira-plugin. This will not only include links to JIRA
in the Thucydides reports, but it will also update the corresponding JIRA issues with links to the corresponding
Story page in the Thucydides reports. To set this up, add the thucydides-jira-plugin dependency to your project
dependencies:

    <dependency>
        <groupId>net.thucydides.plugins.jira</groupId>
        <artifactId>thucydides-jira-plugin</artifactId>
        <version>0.5.4</version>
        <scope>test</scope>
    </dependency>    

You also need to provide a username and password to connect to JIRA, and the URL where your Thucydides reports will be published (for example, on your CI server). You do using by passing in the jira.username, jira.password and thucydides.public.url system parameters.

 
  <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.10</version>
            <configuration>
                <argLine>-Xmx1024m</argLine>
                <systemPropertyVariables>                              
                    <jira.url>http://jira.acme.com</jira.url>                               
                    <jira.username>${jira.demo.user}</jira.username>
                    <jira.password>${jira.demo.password}</jira.password>
                    <thucydides.public.url>http://localhost:9000</thucydides.public.url>
                </systemPropertyVariables>     
            </configuration>
        </plugin>
        ...

Thucydides also generates aggregate reports grouping results for stories and features. To include the JIRA links in these reports as well, you need to set the jiraUrl configuration option in the
maven-thucydides-plugin, as illustrated here:

        
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>3.0-beta-3</version>
        <configuration>
            <reportPlugins>
                <plugin>
                    <groupId>net.thucydides.maven.plugins</groupId>
                    <artifactId>maven-thucydides-plugin</artifactId>
                    <version>@project.version@</version>
                    <configuration>
                         <jiraUrl>http://jira.acme.com</jiraUrl>              
                     </configuration>
                 </plugin>
            </reportPlugins>
        </configuration>
    </plugin>         

If you do not want Thucydides to update the JIRA issues for a particular run (e.g. for testing or debugging purposes), you can also set thucydides.skip.jira.updates to true, e.g.

    $mvn verify -Dthucydides.skip.jira.updates=true

You can also configure the plugin to update the status of JIRA issues. This is deactivated by default: to use this
option, you need to set the thucydides.jira.workflow.active option to ‘true’, e.g.

 
    $mvn verify -Dthucydides.jira.workflow.active=true

The default configuration will work with the default JIRA workflow: open or in progress issues associated with successful tests will be resolved, and closed or resolved issues associated with failing tests will be reopened. If you are using a customized workflow, or want to modify the way the transitions work, you can write your own workflow configuration. Workflow configuration uses a simple Groovy DSL. The following is an example of the configuration file used for the default workflow:

 
    when 'Open', {
        'success' should: 'Resolve Issue'
    }

    when 'Reopened', {
        'success' should: 'Resolve Issue'
    }

    when 'Resolved', {
        'failure' should: 'Reopen Issue'
    }

    when 'In Progress', {
        'success' should: ['Stop Progress','Resolve Issue']
    }

    when 'Closed', {
        'failure' should: 'Reopen Issue'
    }

You can write your own configuration file and place it on the classpath of your test project (e.g. in the src/test/resources directory). Then you can override the default configuration by using the thucydides.jira.workflow property in the Maven pom.xml file or directly on the command line e.g.

 
    $mvn verify -Dthucydides.jira.workflow=my-workflow.groovy

Alternatively, you can simply create a file called <jira-workflow.groovy and place it somewhere on your classpath. Thucydides will then use this workflow. In both these cases, you don’t need to explicitly set the thucydides.jira.workflow.active property.

You can also integrate JIRA issues into your easyb Thucydides stories. When using the Thucydides easyb integration, you associate one or more issues with the easyb story as a whole, but not with the individual scenarios. You do this using the thucydides.tests_issue notation:

 
    using "thucydides"

    thucydides.uses_default_base_url "http://www.wikipedia.com"
    thucydides.uses_steps_from EndUserSteps
    thucydides.tests_story SearchByKeyword

    thucydides.tests_issue "#WIKI-2"

    scenario "Searching for cats", {
        given "the user is on the home page", {
            end_user.is_on_the_wikipedia_home_page()
        }
        when "the end user searches for 'cats'", {
            end_user.looks_up_cats()
        }
        then "they should see the corresponding article", {
           end_user.should_see_article_with_title("Cat - Wikipedia, the free encyclopedia")
        }
    }   

You can also associate several issues using thucydides.tests_issues:

                                 
    thucydides.tests_issue "#WIKI-2", "#WIKI-3"

To use easyb with Thucydides, you need to add the latest version of thucydides-easyb-plugin to your dependencies if it is not already there:

     
    <dependency>
        <groupId>net.thucydides.easyb</groupId>
        <artifactId>thucydides-easyb-plugin</artifactId>
        <version>0.4.15</version>
        <scope>test</scope>
    </dependency> 

As with JUnit, you will need to pass in the proper parameters to easyb for this to work. You will also need to be using the maven-easyb-plugin version 1.3 or higher, configured to pass in the JIRA parameters as shown here:

 
        <plugin>
        <groupId>org.easyb</groupId>
        <artifactId>maven-easyb-plugin</artifactId>
        <version>1.3</version>
        <executions>
            <execution>
                <goals>
                    <goal>test</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <storyType>html</storyType>
            <storyReport>target/easyb/easyb.html</storyReport>
            <easybTestDirectory>src/test/stories</easybTestDirectory>
            <parallel>true</parallel>
            <jvmArguments>
                <jira.url>http://jira.acme.com</jira.url>                               
                <jira.username>${jira.demo.user}</jira.username>
                <jira.password>${jira.demo.password}</jira.password>
                <thucydides.public.url>http://localhost:9000</thucydides.public.url>
            </systemPropertyVariables>     
            </jvmArguments>
        </configuration>
    </plugin> 

Once this is done, Thucydides will update the relevant JIRA issues automatically whenever the tests are executed.

21
Oct

Chrome Integration


Currently Selenium version 2.0 has issues with it’s tabbing when used with firefox.  When tabbing, the focus is not changing.  However, this is not an issue with Google Chrome.  To get around this issue using firefox developers are forced to change the focus on the page by clicking on a different element on the page.  This adds more code to webtests and does not mimic the normal human interactions on a page, which webtests are made to do.

To Setup Webtests

1) You must have Chrome version 12.0.712.0 or newer.

2) Download the binary chromedriver (http://code.google.com/p/chromium/downloads/list)

Macs – http://code.google.com/p/chromium/downloads/detail?name=chromedriver_mac_16.0.902.0.zip&can=2&q=
Windows – http://code.google.com/p/chromium/downloads/detail?name=chromedriver_win_16.0.902.0.zip&can=2&q=
Linux 64 bit –  http://code.google.com/p/chromium/downloads/detail?name=chromedriver_linux64_16.0.902.0.zip&can=2&q=
Linux 32 bit – http://code.google.com/p/chromium/downloads/detail?name=chromedriver_linux32_16.0.902.0.zip&can=2&q=

3) Unzip the file and place it in the user’s bin directory  (e.g. in the /usr/bin directory).

4) on the command line add the parameter -Dwebdriver.driver=chrome

ie mvn test -Dwebdriver.driver=chrome -Deasyb.test=none

To Run Webtests Via IntelliJ

1) Go to the Run/Debug Configuration settings for your test or package

2) Under VM Parameters enter -Dwebdriver.driver=chrome

Configuration Settings

Additional reading:  http://code.google.com/p/selenium/wiki/ChromeDriver

5
Oct

Thucydides Release 0.4.11 – Jira Project Definition


Thucydides version 0.4.11 is now released and available in all of the Maven repositories.  This version
adds the ability to define the jira project, allowing for jira integration to be even easier.  Now the user
only needs to specify the project within the pom file, and the jira number within the @Issue and
@Issues annotations (e.g. ‘@Issue(“#1234”)’) in the unit test class.

The jira project needs to be defined within the Surefire plugin for it to be used within the unit tests.
e.g.

<properties>
    <jira.url>http://my.jira.server&lt;/jira.url>
    <jira.project>MYPROJECT</jira.project>
</properties>
...
<build>
 <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.7.1</version>
    <configuration>
        <includes>
            <include>**/Sample*.java</include>
            <include>**/*Test.java</include>
        </includes>
        <systemPropertyVariables>
            <jira.url>${jira.url}</jira.url>
         <jira.project>${jira.project}</jira.project>
        </systemPropertyVariables>
    </configuration>
   </plugin>
   ...

You also need to provide this to the Thucydides Maven report for the aggregation:

<plugin>
    <groupId>net.thucydides.maven.plugins</groupId>
    <artifactId>maven-thucydides-plugin</artifactId>
    <version>@project.version@</version>
    <configuration>
        <jiraUrl>${jira.url}</jiraUrl>
        <jiraProject>${jira.project}</jiraProject>
    </configuration>
</plugin>

@Issue annotation is used when there is only 1 jira card associated to a unit
test class or scenario, and @Issues is used when multiple jira cards are
associated with a unit test class or a scenario.

Example 1:
Here is an example of using @Issue for when there are multiple cards associated
to the unit test class, and the user wants to specify which of those scenarios
are associated to each scenario. All of the associated jira links will be
automatically associated to the unit test class. 

public class MarketingFeeControlStory
{
....
    	@Test
        @Issue("#3754")
	public void when_a_fixed_amount_is_selected_then_text_box_is_enabled()
	{
		...
	}

	@Test
        @Issue("#3754")
	public void when_none_is_selected_then_the_text_box_should_be_disabled()
	{
		...
	}

	@Test
        @Issue("#3111")
	public void when_at_cost_is_selected_then_the_text_box_should_be_disabled()
	{
               ...
	}

	@Test
        @Issue("#2789")
	public void when_at_cost_is_selected_and_text_box_is_disabled_and_fixed_amount_is_selected_then_text_box_should_be_enabled()
	{
		...
	}
....
}

The report with jira integration will look something like this…

Example 2:
Here is an example of using @Issue to associate a jira card to all
the scenarios by defining the associate jira card at the class level.
Each scenarios within the story will automatically be associated to the
jira card.

@Issue("#3754")
public class MarketingFeeControlStory
{
....
    	@Test 
	public void when_a_fixed_amount_is_selected_then_text_box_is_enabled()
	{
		...
	}

	@Test
	public void when_none_is_selected_then_the_text_box_should_be_disabled()
	{
		...
	}

	@Test
	public void when_at_cost_is_selected_then_the_text_box_should_be_disabled()
	{
                ...
	}
....
}

The report with jira integration will look something like this…


Example 3:

Here is an example of using @Issues to associate jira cards to a
scenario by defining the associate jira cards at the scenario level.
The unit test class will automatically be associated to the jira cards.

public class MarketingFeeControlStory
{
....
    	@Test 
        @Issues({"#3754", "#1211"})
      	public void when_a_fixed_amount_is_selected_then_text_box_is_enabled()
	{
		...
	}
	@Test
	public void when_none_is_selected_then_the_text_box_should_be_disabled()
	{
		...
	}

	@Test
	public void when_at_cost_is_selected_then_the_text_box_should_be_disabled()
	{
               ...
	}
....
}

The report with jira integration will look something like this…