Replacing FF driver with Chrome in JBehave’s tutorial project

Hi All,

Recently I’ve started playing with JBehave or rather with their interesting extension JBehave-web

JBehave-Web is a collection of extension for JBehave that extend its capabilities in ways related to HTTP and the web.

As a starting point I tried running an example project available here: https://github.com/jbehave/jbehave-tutorial.
After getting bored with running all the tests in FF, I’ve decided to replace it with Chrome. Below is the short tut. describing how to do that 🙂

Steps to get you there:

  1. Download chrome driver
  2. Change the webDriver to a PropertyWebDriverProvider
  3. Set System Properties

Step 1)
Download chrome driver that suits your needs: http://code.google.com/p/chromedriver/downloads/list
Extract it wherever you want.

Step 2)
Change the webDriver from FirefoxWebDriverProvider to a PropertyWebDriverProvider that allows running your tests with Google Chrome.
Edit etsy-steps.xml located […]/jbehave-tutorial/etsy-stories-java-spring/src/main/resources/etsy-steps.xml
and replace a FirefoxWebDriverProvider bean with a PropertyWebDriverProvider:

<bean id="driverProvider" class="org.jbehave.web.selenium.PropertyWebDriverProvider" >
</bean>

Step 3)
To set System Properties, edit Maven’s etsy-stories-java-spring module config file: […]/jbehave-tutorial/etsy-stories-java-spring/pom.xml
Follow this xpath to add the new props in the right place:

/pom:project pom:build/pom:plugins/pom:plugin/ pom:executions/pom:execution[2]/pom:configuration

                <systemProperties>
                    <property>
                        <name>browser</name>
                        <value>chrome</value>
                    </property>
                    <property>
                        <name>webdriver.chrome.driver</name>
                        <value>filepath/to/the/chromedriver/you/extracted/in/step1</value>
                    </property>
                </systemProperties>

ps. in case you’ll encounter problems solving all the dependencies while running the demo project, just add repos listed below to your main project Maven config file: ([…]/jbehave-tutorial/pom.xml)

  <repositories>
    <repository>
      <id>jbehave-web-repo</id>
      <name>jbehave web repo</name>
      <url>https://nexus.codehaus.org/content/groups/snapshots-group</url>
    </repository>
  </repositories>

  <pluginRepositories>
    <pluginRepository>
      <id>codehausSnapshots</id>
      <name>Codehaus Snapshots</name>
      <releases>
        <enabled>false</enabled>
        <updatePolicy>always</updatePolicy>
        <checksumPolicy>warn</checksumPolicy>
      </releases>
      <snapshots>
        <enabled>true</enabled>
        <updatePolicy>never</updatePolicy>
        <checksumPolicy>fail</checksumPolicy>
      </snapshots>
      <url>https://nexus.codehaus.org/content/groups/snapshots-group</url>
      <layout>default</layout>
    </pluginRepository>
  </pluginRepositories>

Cheers,
J

Testing & Continuous Integration…. how to do it right ??? :)

You might be thinking that you’ve just found a place that will answer this question, unfortunately this time (or as usually) it’s a question to you guys 🙂

How to do it right??
I don’t know yet, but I’ll try to find that out!

The reason behind it is rather trivial, I recently faced the reality and now I have to move with testing towards a CI environment.

After pondering over that matter for few mins and doing a quick research, I came with few things (and two that bothers me a bit) that I definitely have to deal with.

Initially I’d like to somehow deal nicely with “challenges” like:

  • running tests in multiple CI environments [i.e. Dev, Staging, QA]
  • app versioning (i.e. different behaviours between different supported versions)

After figuring that out, it’d be super-cool to find a good (flexible & future proof) solution to unify the way we:

  • create random test data (fixtures) on the fly for each: test run, build, release etc. (and if needed use some static data)
  • expose that newly created data to any test that is currently running in a selected environment
  • safely remove that test data from system under test (SUT).
  • (optionally) store some historical test data (i.e. test inputs and outputs) in a repository.

I don’t if that’s good way to address that problem, but I’m hoping that you can help me with that.
So please don’t be shy commenting and giving some advices 🙂

Cheers,
J