Page 1 of 1

Building an Automation Testing Framework for WebApps Part 2

#1 NeoTifa  Icon User is offline

  • NeoTifa Codebreaker, the Scourge of Devtester
  • member icon





Reputation: 4045
  • View blog
  • Posts: 18,067
  • Joined: 24-September 08

Posted 18 April 2017 - 01:32 PM

Building an Automation Testing Framework for WebApps in Ruby by NeoTifa

~~~~~~~~~~~~Index~~~~~~~~~~~~

Part 4.) Cucumber Intro
Part 5.) Features and Scenarios
Part 6.) Step Definitions
Part 7.) Hooks

~~~~~~~~~~~~Part 4~~~~~~~~~~~

Part 4.) Cucumber Intro

Cucumber is a gem used as a testing framework. How it works is one would write a script, called a gherkin, in the gherkin format, then define the steps in a separate steps file. This way a scenario is an easily-readible to anybody, including business, as it's written like a regular sentence. Cucumber supports most all languages (including pirate :D/>), so you don't have to worry about translations unless you're the ones defining the steps.
More info on language support

~~~~~~~~~~~~Part 5~~~~~~~~~~~

Part 5.) Features and Scenarios

A feature is basically a high-level story, but in reality the feature files are used kinda like storycards. The features include a bunch of scenarios, which are the actual tests being ran. To declare a file as a feature, you simply create a file somewhere under the 'features' folder, and have the extention .feature.
Posted Image

At the top of the feature file, you write "Feature: " then a short description/title. Underneath you can write whatever text you want, such as comments, prereqs, scope, descriptions, etc. These will simply not be parsed, and are there for documentation purposes. Each scenario is declared with "Scenario: " or "Scenario Outline: " (more on that later) with a short description. Individual steps shall go beneath.

Posted Image

The difference between a scenario and scenario outline is that a scenario outline has a mini table underneath the scenario delcared with "Examples: ". It will error out if you put "Scenario Outline" but no "Examples" underneath.

Steps begin with certain keywords that are understood by the user to have certain implications, such as:
	[b]Given[/b] the user has this precondition
	[b]And[/b] is in this state
	[b]When[/b] the user does some action
	[b]And[/b] another action
	[b]Then[/b] some magical thing will happen
	[b]But[/b] not some non-magical thing



The step beginnings (given, and, etc.) are frankly interchangeable and are there for readability, what really matters is the text afterwards. These are the steps that are going to be defined. When you first write them in RM, they'll be highlighted if they're not defined, like in the screenshot above. If you run the test it will fail saying undefined steps. In RM, there will be a little lightbulb that will come up, and you can click "define step" and it will prompt for a new steps file or existing (if there is one).
Posted Image
Posted Image
Posted Image
If there are none, it will create one for you in a folder called step_definitions. Unless you rename it, it'll create a file called my_steps.rb. If you're not using RM, you can do it manually by creating a file called my_steps.rb yourself, preferably in a step_definitions folder for easy finding. You will then have to create all the steps yourself. If you ran the test previously and it failed due to undefined steps, it will handily give you a template in the output. How fun is that?!

Posted Image
This is how a step looks. It will say pending at first. When you run the test with pending steps, it will skip all pending tests and say it is pending, so it neither passes or fails.
Posted Image
Posted Image
Posted Image

Once you've put code, regular Ruby code, inside the steps to do what you want the steps to do, you can run it again.
Posted Image
Posted Image

Scenario Outlines are totally handy because you can run a test multiple times giving different parameters.
Posted Image
When giving the Examples table, the first row is the param names, and the values are separated by pipes '|'. This will run several instances of this test. For the last 2, we can expect it to fail, which it does.
Posted Image

There is also something called 'background' that is a list of common steps that would be executed before each scenario, but I usually just throw some of that in the hooks (more later).

~~~~~~~~~~~~Part 6~~~~~~~~~~~

Part 6.) Step Definitions

We've touched on this above in the brief overview of scenarios and features. The steps are just a plain English sentence that would describe what a user would do on the application. There are a couple of different ways to approach this, and you can be as explicit or as vague as you want. The steps could be as simple as clicking a button or as complex as doing a whole multi-page process beforehand. However, since we're programmers, we want to reuse as much as possible. As you could see from my above example, I used variables so any value I desire can be plugged in and the functionality would change appropriately. A good example would be:

And the user clicks the <button> button



The <button> portion would be a variable that would be named button. If you go to put this in the examples table below the scenario it would be highlighted, and if it's just a regular scenario, when you define the step via clicking the lightbulb it will automatically produce

And /^the user clicks the (.*) button$/ do |button|
	pending 
end



Normally it would initialize as 'arg' not 'button', so this is kinda handy. Another handy trick you can do to save code repitition is optional parts of your steps.

And the user clicks the <button> button <n> times



Since they have the same first half, you can add this conditional at the end

And /^the user clicks the (.*) button (?:(/>/>.*) times)?$/ do |button, n|
	pending 
end



This makes whatever is in those parenthesis optional. You could also make several conditionals using |.

And /^the user clicks the (.*) button (?:(/>/>.*) times | twice | thrice)?$/ do |button, n|
	pending 
end



So that way 'And the user clicks the search button twice' would be just as valid as 'Then the user clicks the login button 10 times' (remember the first word is interchangeable).

~~~~~~~~~~~~Part 7~~~~~~~~~~~

Part 7.) Hooks

Hooks are little bits of code that can be run during certain parts of a test. You can 'hook' code at the beginning and/or end of a run, feature, scenario, or even steps. You can also place @ tags to tag scenarios to run hooks only on them (or run only them, but that's a run criteria, not a hooks thing). I'm going to only go over a few more frequently used examples.

Before do
	# every scenario
end

After do |scenario|
	# every scenario but you can do this:
	if scenario.failed?
		# stuff
	end
end

Before('@dothis', '[email protected]') do
  # only happens for tags @dothis but no [email protected]
end



You can read more here.

That is all for now, I will get back later with webdrivers and Selenium/Watir.

Is This A Good Question/Topic? 1
  • +

Replies To: Building an Automation Testing Framework for WebApps Part 2

#2 NeoTifa  Icon User is offline

  • NeoTifa Codebreaker, the Scourge of Devtester
  • member icon





Reputation: 4045
  • View blog
  • Posts: 18,067
  • Joined: 24-September 08

Posted 09 August 2017 - 01:43 PM

Sorry for the delay, the screenshots and test suite I had presented a security risk, so I've been working on a new site to "test", so once I build that out I will finish this series. I didn't forget about you guys <3.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1