Skip to main content

Posts

assertTrue vs assertEquals for text verification

   We all do text validation in our automation tests to validate whether the returned value is the same as the expected one or not. I see that many folks use the assertTrue command instead of assertEquals to validate the returned text while using assertions from TestNG or JUnit. Let's see why using assertTrue is bad practice for text comparison.   assertEquals public static void assertEquals(String actual, String expected) Asserts that two Strings are equal. If they are not, an AssertionError is thrown. Parameters: actual - the actual value expected - the expected value assertTrue public static void assertTrue(boolean condition) Asserts that a condition is true. If it isn't, an AssertionError is thrown. Parameters: condition - the condition to evaluate   Let’s say that I have an automated test script where I would like to verify the Title of the home page -  we are doing the check using assertTrue as well as assertEquals methods.   String Exp

Want to clear all inputs in a form quickly?

While submitting a form, at times, we get a use case where we need to first clear the default/pre-filled values of all the fields in the form and then enter our desired value. Usually, we do this for every field: WebElement firstName = driver.findElement(By.id("Form_submitForm_FullName")); email.clear(); email.sendKeys("Dheeraj"); Here we are locating an element, and assigning it to a WebElement. After that, we send commands: > clear() to clear the value into the input field  > And then the sendKeys() to fill it in with a new desired value. But isn’t it time-consuming to find all the fields in the form and then clear each field 1 by 1?  Here is the faster alternative… You can send a Javascript command to clear all the fields in one shot : document.getElementById('Form_submitForm').reset() This is just an alternative to reduce some test execution time. You can use any approach that works best for you. Here is the working example: public class Form { W

Properties Files in Java with Owner library

When we create an automation test framework, most of us use properties files to get any configuration like URL, credentials, or whatever data you need to change frequently as a configuration.   In this blog, we will discuss how we can easily manage properties files with the Owner Java library makes properties file management very easy, and minimize the code required to handle application configuration through Java properties files. If you are using Maven, things are quite simple, just add the following section to your pom.xml: <dependencies> <dependency>     <groupId>org.aeonbits.owner</groupId>     <artifactId>owner</artifactId>     <version> 1.0.12 </version> </dependency> </dependencies>   Note * At the time of writing this page, the latest version is 1.0.12, but you need to check if there is any newer version here: https://mvnrepository.com/artifact/org.aeonbits.owner/owner   Suppose your properties file is defined as Conf

Test Data Supplier (TestNG DataProvider wrapper)

  Test Data Supplier (TestNG DataProvider wrapper) If you are a big fan of Stream and Collection API for data manipulation in the modern Java world, give a shot to this library that contains TestNG DataProvider wrapper (as of writing this blog, the latest version is based on TestNG 7.8.0) which helps to supply test data in a more flexible way. Supported return types Collection Map Entry Object[] double[] int[] long[] Stream / StreamEx Tuple A single Object of any common or custom type As it can return StreamEx, it gives you more power to play with flatmap, indices, transposing, etc. You can find more details and sample Gradle/Maven projects on their official GitHub repository page :  https://github.com/sskorol/test-data-supplier Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

Test Automation Fundamentals

 

How to upload a pdf file using REST Assured?

 If you use this code as mentioned in few other blogs and videos:   Map<String, String> headers = new HashMap<String, String>(); headers.put("Content-Type", "multipart/form-data"); byte[] fileContent = FileUtils.readFileToByteArray(new File(filePath)); RestAssured.given().headers(headers).body(fileContent).post(url);   There are high chances that you will get errors related to content-type or "400 - Request is not a multipart request". So, the solution is to use: .multiPart("file", new File("/path/to/file"),"application/pdf"). Please note that I have used "application/pdf" as 3rd param in the multiPart method and this value should be passed as per the file type that you are uploading like for the png file it should be "application/octet-stream", for JSON file it should be "application/JSON". multiPart is an overloaded method that can take max 3 parameters:   a)

How to run your postman (Newman) automation collection in a Continuous Integration environment like Azure DevOps build Pipeline?

  How to run your postman (Newman) automation collection in a Continuous Integration environment like Azure DevOps build Pipeline? Postman Introduction: Postman is a tool that simplifies each step of building and testing APIs. If you've ever used it in your development or testing phase, you must already know what an incredible tool it is. It presents the possibility to automate your API tests and integrate them into your CI/CD pipeline to make certain that any code changes won’t introduce any new regression issues in upper environments like QA, Stage, Production, etc. Newman Introduction: Newman is a tool, using which one can effortlessly run and test Postman Collections directly from the command line. Azure DevOps CI/CD Introduction: Azure DevOps by Microsoft Azure is one of the leading tools that automate CI/CD's process. Using continuous integration and continuous deployment with Azure DevOps, these pipelines are used to construct build-deploy-test workflows used mainly in c