Everything About Testing

Monday, 30 March 2015

Some time you might have seen that even though your testNG test is failing but still ant shows it as build successful.If you want to make your build run as failed if any of TestNG tests fails, then you need to add following testNG failure property in your build.xml

Friday, 20 February 2015

A DataProvider in TestNG is a method in a test class, which provides an array of varied actual values to dependent test methods.(WIKI)Check below how to pass class object to test Method using DataProvider.Please note in Test method, passed parameter type should be of type of Object that you have added to your object array in dataprovider method.

public class Dummy { private String name; private int salary; public Dummy(String name, int salary){ this.name=name; this.salary=salary; } public String getName() {return name; } public int getSalary() {return salary; }}One must Remember Point about test iterationsObject[][] data = new Object[1][1];With above data ,your test will run 1 time and will take one parameterSimilarlyObject[][] data = new Object[2][1];and this one will run 2 times and will take one parameter.

Tuesday, 10 February 2015

CSV:A CSV is a comma separated values file, which allows data to be saved in a table structured format. CSVs look like a garden-variety spreadsheet but with a .csv extension (Traditionally they take the form of a text file containing information separated by commas, hence the name).(Source Wiki)If someone opens CSV with notepad or textpad or some other editor it may look clumsy and difficult to read,Its always a good idea to open it using MS Excel for easy formatting and readability.Below is the Java code to read from CSV file, herein we are trying to read each line from csv file, splitting it by delimiter comma and saving each item in a String array.CSVFile.csvThis,is,code,for,reading,csv,filethis,is,first,linethis,is,second,linethis,is,third,line****************************************************************************************package test;import java.io.BufferedReader;import java.io.FileNotFoundException;import java.io.FileReader;import java.io.IOException;import java.util.Arrays;public class ReadCSV { public static void main(String args[]) { ReadCSV test = new ReadCSV(); test.readCSV();

Saturday, 19 October 2013

WebDriver is a web automation framework which allows us to execute tests against different browsers.We can use any programming language(Java,.Net,PHP,Python,Perl,Ruby) to write test scripts.

we can use conditional operations like if-then-else or switch-case

Lets see few similarities between WebDriver and Selenium RC
Both allows us to use programming language in designing test .
Both allow us to run tests against different browsers.

Selenium RC’s architecture is bit more complicated.
We need to launch a application called Selenium Remote Control Server before starting testing
Selenium RC works only using JavaScript for its every command. That means that everything you write is eventually translated into Javascript and run in the browser.
The browser will obey the instructions of Selenium Core, and will relay its response to the RC Server.
The RC Server will receive the response of the browser and then display the results.
RC Server will fetch the next instruction from your test script to repeat the whole cycle.

However WebDriver interacts directly with browser and uses the browser’s own engine to control it,that is what makes webdriver faster.

Remember that WebDriver operates on the OS level. Also remember that different browsers communicate with the OS in different ways. If a new browser comes out, it may have a different process of communicating with the OS as compared to other browsers. So, you have to give the WebDriver team quite some time to figure that new process out before they can implement it on the next WebDriver release.
However, it is up to the WebDriver’s team of developers to decide if they should support the new browser or not.

Note that while Selenium RC has been oficially deprecated, the WebDriver is now being developed rapidly and it still suffers from several child-illnesses and is not in its full strength. That said, using WebDriver, you can do anything Selenium RC can do. And sometimes more. With an occasional minor bug.

I will recommend the following link for any one who is trying to learn webdriverSeleniumhq.org

Monday, 8 April 2013

We have been using VSTS CodedUI
Tests for over 3 years now for functional regression testing and have been
intrigued by this complex yet simple tool. Yes you read it right complex yet
simple because it must have a very complex architecture to support so much in a
single tool yet for the user it is very simple and a breeze to work. The
mechanics behind any test automation tool are very intricate yet very
interesting. The basics remain the same across the tools with differences in
the architectural details.Let’s take a plunge into the architectural details of
UITest Framework that the testing components of Visual Studio use and
understand how an automation tool works. Let’s have a glance at the
architecture of CUIT Framework:

Let us go through the various
blocks one by one and try to understand their significance starting from the
plug-ins.

1.Plug-ins / Technology Adapters: A
plug-in or a technology adapter is a module that understands the corresponding
User Interface technology and provides the UI technology specific services to
rest of the modules. The role of a technology adapter is to understand the
technology for which it is designed and provide services to the rest of the
layers especially the abstraction layer. For example, to record/playback user
actions on IE we have the Web Plug-ins (MSHTML/DOM) that understands the
technology on which IE is based (i.e. MSHTML/DOM). It can thus communicate with
IE and the automation tool thus providing a communication medium between the
two thereby enabling the record and playback services.

2.Abstraction Layer: Next up is the
abstraction layer which helps abstract rest of the code from various technologies.
The abstraction layer has a very important role to play when supporting
multiple technologies. This layer sits between the plug-ins and rest of the
modules. The record and playback engine speaks to the abstraction layer which
makes the engine independent of the technology being automated. The abstraction
layer translates everything coming from the plug-ins and feeds the test engine
with the input that it can understand and also send instructions back to the
plug-in for playback.

3.Recorder
and Playback Modules

Recorder: The recorder first records
the raw steps (user actions) and based on the filter\aggregation rules, these
raw steps are converted into filtered steps or user-intention.

-Filter rules
are the rules based on which the recorder can filter out any
unwanted/unintended actions like back-spaces pressed while typing into and
edit-box etc.

-Aggregation
rules are used to club multiple user actions into a single step wherever
applicable. Eg. Going to start menu, launching IE and typing URL in the address
bar can be aggregated into a single step as it can be performed in a single
step while playing back the recording. This is also called as Intent Based recording.

Playback: The playback module has a rich set of public
APIs for the users that they can use to write robust tests. The APIs can be
used to interact with the AUT in many ways like performing click action on a
button or a hyperlink or selecting an item from a drop-down list. It also has
property provider which gives information on properties supported by each
control in the AUT and browser services for browser specific operations like
navigate to URL, clear cache etc.

4.The
two clients that are available as of today sit on the top layer.

-Test
Runner: The Test Runner uses the UITest framework to do Fast Forwarding for
manual tests. The Test Runner interprets
(using the interpreter module which actually forms a part of the Test Runner)
the recording on the fly and calls appropriate API on the playback side to
perform the user actions on the UI of AUT.

-Coded UI
Test (CUIT):The Coded UI Test which effectively is a Visual Studio client
generates code out of the recording performed by the Recorder module. It uses
information provided to it by property provider for each control to create definitions
for the controls (in the AUT) and add appropriate API calls to replicate the
user actions performed during recording session. These properties are used to
identify the controls in the AUT during playback session. The users can
alternatively hand-code the entire CUIT using the rich set of public APIs.

To summarize we can generalize
the above discussed components and understand how automation tools work in
general (of course the implementation/architectural details will remain
different for different tools). Happy Automation!