#TECH

Unit Testing and GUI Testing- When should you use what?

Software Testing is the process of verifying and validating if the software which we have built is working as per expectations. A software tester should have the intent to find defects and make sure that the application is working properly. In order to achieve this, different test techniques such as automation testing, performance testing, unit testing are used. As GUIs are critical components of today’s software, there is more emphasis on GUI testing.

GUI v/s Unit testing

A lot of people are automating their web applications. This is definitely a good thing for testing per se. But what happens is that they focus more on the tools rather than the testing.

Why is that a problem? Because testing of a web application shouldn’t be done through just the graphic user interface (GUI). Instead, the application should be thoroughly tested using unit testing as well. GUI tests tend to be slower and more fragile. Through unit testing, we can reduce the time effectively both in writing and execution of test cases. Also, there will be less chance of missing functional test cases which are to be executed as the focus will only be on the functionality in Unit Tests, whereas in GUI testing the focus is more on the integration of the functionalities.

An example of something that could be tested using unit tests is the Textbox validation. Data is entered in String format in the application. The logic that validates whether it is following all the validation applied should probably be a unit test. There will be some code that receives a String or something similar and returns true or false. There will be another unit test which will receive some numerical value and return true or false.

Unit testing aims to test small portions of your code (individual classes/methods) in isolation from the rest of the application which provides more focus on the functionality testing.

The concat method below accepts a boolean value as input and appends the two strings passed in only if the boolean value is true:

public String concat(boolean append, String a, String b) {
       String result = "";
       If (append) {
           result = a + b;
                           }
       return result.toLowerCase();
   }

 

The following is a test case for the above method:

@Test

public void testStringUtil()

{

String result = stringUtil.concat(true, "Hello ", "World");

Assert.assertEquals("hello world", result);

}


Here, if I try to test the same functionality by GUI, I would need to enter two different Strings in different text boxes e.g. text boxes for First Name and Last Name in any application and verify on some other page after navigating that the name after concatenation is displayed correctly. With a tool such as selenium, it would take much longer to write a simple test case to verify the above scenario.

However, some functionalities should only be tested through the user interface. GUI testing may consist of system/ functional/acceptance testing, where the whole system can be tested together to ensure it does what it is supposed to do under real-life circumstances.

In such cases, it is valuable to separate responsibilities. Selenium is not just a tool for verification but also allows navigation using an actual browser. Verification should be done using other tools. They include unit testing frameworks or BDD frameworks. Being a Quality Engineer I prefer to use Cucumber. It depends on the application and its usability.

Separating navigation from verification is one way to understand the problem. It leads to a methodology known as the Page Object Pattern. This means that using that page object makes it easier to adhere to the Single Responsibility Principle, SRP. Using page objects save a lot of problems when the layout, not the logic, is changed in a web application.

What is a page object?

It is a class that abstracts away interaction with a web page. An example could be entering values in a form and submitting it. The methods in the page object know the name of different widgets so the user can work at a higher abstraction level. Instead of working on the level send-keys to web element, the user can say, “buy three different types of Headphones” and not care about how the widget that is used is located in the code.

Instead of mixing the verification code and navigation code, the test writer is able to focus on the expected behavior and nothing else.

Unit tests are meant to be small, fast, encapsulated tools to test classes and methods in isolation. They don’t test what happens to your application under real-world conditions. How does your app behave under Windows 2000, Windows 8, Windows 10, Mac, Linux? What happens to your server when 10 or 1000 users access it simultaneously? How about the same test with 6 years of data on 70,000 accounts?

You know the answer- functional testing via the user interface is usually the most effective way to broaden the scope and depth of your testing to include real-world scenarios which integrate all the components of your application system, while unit tests are used to check whether units of applications are working as per design and handling error and exception more neatly. Both positive and negative conditions should handle properly.

Hope this blog helps you in making better decisions.