How to Develop Test Scripts Using Top 5 Most Popular Test Automation Frameworks (Examples)

When you step into automated testing, the term “automated testing framework” will inevitably cross your path. This term might seem daunting and complex to comprehend and implement for some.

This guide is aimed at demystifying automated testing frameworks as much as possible. For a comprehensive understanding, take a look at all our tutorials in the “‘Automation Testing Tutorials’ series here.”

An automated testing framework, simply put, is a “framework of guidelines” that assist us in script-writing in ways that cut back on maintenance efforts.

In order to fully comprehend the idea of a framework, we first need to learn how to compose simple scripts and then understand how to integrate a framework over them.

In automated testing, we compose scripts. Scripting mainly involves three steps:

1. ORGANIZATION
2. ACTIVITY
3. AFFIRMATION

Here’s a detailed explanation of each step, along with examples:

#1. ORGANIZATION or Object Recognition

Objects (buttons, dropdowns, etc.) can be recognized by their IDs, names, or window titles. For web applications, we can use their user IDs, XPath, CSS, or class names for recognition. If none of these methods work, mouse coordinates can be employed as a last resort, although this is not a reliable method.

Here’s an example using Selenium WebDriver with C#, where we recognize objects using their IDs (in a web application):

 IWebElement txtServer = _webDriver.FindElement(By.Id("tfsServerURL")); 

Here’s another example using MS Coded UI for a desktop application:

 WinButton btnAdd = new WinButton(calWindow);
btnAdd.SearchProperties[WinButton.PropertyNames.Name] = "Add"; 

Once identified, these objects are organized and saved in UIMaps or an Object Repository for reuse in our scripts. Hence, this step is called ORGANIZATION.

#2. ACTIVITY on the Recognized Object

With the objects recognized, we perform various actions on them using either the mouse or the keyboard. For example, we can click, double-click, mouse hover, drag-drop, or type in text boxes. Any activity performed on these objects is part of this second step.

Example 1: (Selenium WebDriver with C#)

 txtServer.Clear();
txtServer.SendKeys(“Some sample text”); 

Example 2: (MS Coded UI with C#)

 Mouse.Click(buttonAdd); 

#3. AFFIRMATION

Affirmation involves comparing an object to an anticipated result. For instance, if we press 2+3 on a calculator, the screen should display 5. Here, the expected result is 5. This concept is explored in more detail in our initial tutorial.

Here’s an example of an affirmation:

 Assert.AreEqual("5", txtResult.DisplayText); 

Almost every automated testing script comprises these three components: Organization, Activity, and Affirmation.

Let’s now delve into a comprehensive script incorporating all these steps. This script launches a calculator, presses 1 + 6, and checks whether the screen displays 7 or not.

Example A:

[TestMethod]
public void TestCalculator()
{

var app = ApplicationUnderTest.Launch("C:WindowsSystem32calc.exe");
//Object identification part (ORGANIZATION)

//----*Calculator Window----*//
WinWindow calWindow = new WinWindow(app);
calWindow.SearchProperties[WinWindow.PropertyNames.Name] = "Calculator";
calWindow.SearchProperties[WinWindow.PropertyNames.ClassName] = "CalcFrame";

//----*Button1 ----*//
WinButton btn1 = new WinButton(calWindow);
btn1.SearchProperties[WinButton.PropertyNames.Name] = "1";

//----*Button Add ----*//
WinButton btnAdd = new WinButton(calWindow);
btnAdd.SearchProperties[WinButton.PropertyNames.Name] = "Add";

//----*Button 6 ----*//
WinButton btn6 = new WinButton(calWindow);
btn6.SearchProperties[WinButton.PropertyNames.Name] = "6";

//----*Button Equals ----*//
WinButton btnEquals = new WinButton(calWindow);
btnEquals.SearchProperties[WinButton.PropertyNames.Name] = "Equals";

//----*Text Box Results----*//
WinText txtResult = new WinText(calWindow);
txtResult.SearchProperties[WinText.PropertyNames.Name] = "Result";

//(ACTIVITIES Part)
// Click '1' button
Mouse.Click(btn1);

// Click 'Add' button
Mouse.Click(btnAdd);

// Click '6' button
Mouse.Click(btn6);

// Click 'Equals' button
Mouse.Click(btnEquals);

//evaluate the results (AFFIRMATIONS)
Assert.AreEqual("7", txtResult.DisplayText, “Screen is not displaying 7");

//close the application
app.Close();

}

What’s wrong with that script?

The script is straightforward to comprehend, and I hope you wrap your head around the concept of the three ‘A’s in the above example. However, the script is not flawless.

This script does not allow for uncomplicated maintenance. Let’s revisit the calculator example. If we had to write test cases for each functionality of the calculator, there would be numerous test cases. If there are 10 test cases and the same object has to be defined in each test, any alteration in the object’s name or ID would necessitate updating the object recognition part in all 10 test cases.

Here’s the “ADD” button in the script, for example:

 WinButton btnAdd = new WinButton(calWindow);
btnAdd.SearchProperties[WinButton.PropertyNames.Name] = "Add"; 

Suppose this line is deployed in 10 test cases. Suppose the developer changes the button’s name from “Add” to “Plus” in the calculator’s next version. Now, when we run our test cases, they will fail, and we have to update the above line in all 10 test cases.

 btnAdd.SearchProperties[WinButton.PropertyNames.Name] = "Plus"; 

To refine this test case, we need to abide by the renowned DRY principle in our coding. DRY stands for “Don’t Repeat Yourself.” We should define the object identification part in such a manner that the object is identified only once and can be invoked anywhere.

Take a look at the improved script below:

Example B:

//defining the objects outside the script and only once.
ApplicationUnderTest app = null;
public WinWindow calWindow
{

get {
WinWindow _calWindow = new WinWindow(app);
_calWindow.SearchProperties[WinWindow.PropertyNames.Name] = "Calculator";
_calWindow.SearchProperties[WinWindow.PropertyNames.ClassName] = "CalcFrame";
return _calWindow;
}
}

public WinText txtResult
{
get
{
WinText _txtResult = new WinText(calWindow);
_txtResult.SearchProperties[WinText.PropertyNames.Name] = "Result";
return _txtResult;
}
}

//making functions for similar tasks
public void ClickButton(string BtnName)
{
WinButton button = new WinButton(calWindow);
button.SearchProperties[WinButton.PropertyNames.Name] = BtnName ;
Mouse.Click(button);
}

public void SumTwoNumbers(string number1, string number2)
{
ClickButton(number1);
ClickButton("Add");
ClickButton(number2);
ClickButton("Equals");
}

//Test case becomes simpler and more maintainable.
[TestMethod]

public void TestCalculatorModular()
{
app = ApplicationUnderTest.Launch("C:WindowsSystem32calc.exe");

//conduct all the operations
SumTwoNumbers("6", "1");

//evaluate the results
Assert.AreEqual("7", txtResult.DisplayText, “screen is not displaying 7”);

//close the application
app.Close();

}

In the above example, we dissociate the calWindow and txtResult objects and move them to the top to make them available across different test methods. We define them only once, and we can apply them to as many test cases as needed.

We also devise two functions: ClickButton(), which accepts a button name and implements a click on it, and SumTwoNumbers(), which delivers two numbers, adds them, and uses the ClickButton function within.

As we “refine” our code and make it reusable and easily maintainable, we start applying an automated testing framework. And that’s when things get interesting.

See Also: <a title=”https://iptvassist.com/why-do-we-need-test

Related

Best Iptv Service Provider 2024 With 40k+ Channels And 150k+ VOD . Hurry Up