BDD Mobile Test Automation - Integration of Cucumber with Appium

Behavior Driven Development (BDD) is very popular with many Agilists out there, specially those focused on Testing. However my view is that BDD is not about Test Automation, it is about collaboration so that the expected behavior of the application can be determined. Cucumber happens to be the tool of choice to implement BDD.  While doing this for web applications, we can drive the features through WebDriver.

Lately the application development has been inclined towards mobile apps and we need to extend our exiting BDD frameworks to handle app, be it Android, iOS or Win Mobile.

Appium is a neat tool for anyone who has exposure to WebDriver, irrespective of that also it is an excellent tool for mobile testing.

Here is my video of running Appium tests for android app using Cucumber.

You can create the Maven project using the following POM.xml:

1:  <?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?>  
2:  <project xmlns=&amp;quot;http://maven.apache.org/POM/4.0.0&amp;quot;  
3:  xmlns:xsi=&amp;quot;http://www.w3.org/2001/XMLSchema-instance&amp;quot;  
4:  xsi:schemaLocation=&amp;quot;http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd&amp;quot;>  
5:  <modelVersion>4.0.0</modelVersion>  
6:  <dependencies>  
7:  <dependency>  
8:  <groupId>junit</groupId>  
9:  <artifactId>junit</artifactId>  
10:  <version>4.11</version>  
11:  <scope>test</scope>  
12:  </dependency>  
13:  <dependency>  
14:  <groupId>org.seleniumhq.selenium</groupId>  
15:  <artifactId>selenium-java</artifactId>  
16:  <version>LATEST</version>  
17:  <scope>test</scope>  
18:  </dependency>  
19:  <dependency>  
20:  <groupId>info.cukes</groupId>  
21:  <artifactId>cucumber-java</artifactId>  
22:  <version>1.0.14</version>  
23:  <scope>test</scope>  
24:  </dependency>  
25:  <dependency>  
26:  <groupId>info.cukes</groupId>  
27:  <artifactId>cucumber-junit</artifactId>  
28:  <version>1.0.14</version>  
29:  <scope>test</scope>  
30:  </dependency>  
31:  </dependencies>  
32:  </project>  

The code for JUnit test runner is as below:

1:  package com.qaagility.atacalc;
2:  import cucumber.api.CucumberOptions;
3:  import cucumber.api.junit.Cucumber;
4:  import org.junit.runner.RunWith;
5:  @RunWith(Cucumber.class)
6:  @CucumberOptions(format ="pretty", tags={"@only"}, features = "test/resources/ATA_Calc.feature", monochrome=true)
7:  public class TestRunner {
8:  }

Back after a long time and wishing you a very happy new year to you all!!

So what does 2013 holds for us in the testing area, I find this year full of lot of prospects and exciting developments for the testing world.

As Agile is changing from the "buzz-word" to "must-have" for most of the clients, I expect to see lot of traction in this area.  Historically the Agile has been more of the developers' baby, they seem to have been driving it. However lately the shift can be seen where the distinction between the developers and testers seem to have reduced significantly and we are looking at Agile teams where the team members are "all-rounders" with cross-skills.  Earlier it was nice to have teams like that and we aspired for such Agile teams and for lucky ones eventually the teams transformed into this using pairing and extensive training and coaching.

The testers now have been evolving and getting more development-centric, and developers getting hang of testing beyond Unit level.  Due to this leveling of the skills, now testers seem to placed in a better position to drive the development activity, some may term it is TDD but what I foresee is a "less intense" TDD. What do I mean by that?

TDD in pure sense would mean that we strictly write the tests first and that gives the scope of development to the developers and they write code that passes the test and stop at that.  A less intense TDD would be that you write the test first however it does not take the onus of describing the scope for the developers.  So developers would still refer to the SRS (reqt doc) in order to code, the difference being that they will have high priority tests ready for them to conformance to requirements.  Subsequently more testing would be done at integration and acceptance level to get the appropriate coverage as required.  So if you are not comfortable calling this variation of TDD then we can name is around the concept of early testing  (mind you, these are not static tests from V model).

This variation of testing gives ample powers to testers in an Agile (or traditional) methodology and also brings in concept of quality early in the SDLC.

The Future of Testing

http://saucelabs.com/blog/index.php/2010/11/the-future-of-testing/

Selenium Jobs Explode

IE9: users will soon be out of date, warns browser expert

Selenium User Meetup 2008: Lightning Talks

Article info : Soft Skills that Make a Tester

Article info : Soft Skills that Make a Tester