My Testing Thoughts

   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. ...

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...

  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.

  To integrate TestRail with any automation suite, we can use the TestRail APIs with the following basic flow: Create test cases in TestRail.   Provide those unique Test IDs from TestRail to your TestNG tests. Run automation: Create a test suite in TestRail before test execution using the TestRail API. And then post the run results according to test automation results using the TestRail API. Create test cases in TestRail:        2.  Creating a custom annotation and calling it as TestRails:      3.  After that, we associate our test cases with actual Test Rails ID’s like:     4.  These ids 1, 2, 3, and 4 are test case ID that we got from TestRail test cases, you can hover over your test case and see that ID in the URL (as shown below):     5. Create a Test Run in TestRail through code,  as you can look at that we have not created any Test Run manually (see below): Snapshot of TestRail before execution of...

  If your UI automation code takes screenshot on failure in test method or page method, then it’s not good. We should handle that using a listener Or have a base class containing AfterMethod annotation that captures screenshots on failure. Use lateral approach (i.e. base class with afterMethod) if you aren’t using listeners in your framework. Go through this well explained article by Alex Siminiuc for more details: https://levelup.gitconnected.com/the-good-the-bad-and-the-ugly-of-taking-screenshots-with-selenium-and-java-c9da23e09842

To tackle the disadvantage of Hard Assertions where we want to continue the execution even if some assert fails and see the result at the end of the test. Soft Assertions are the type of assertions that do not throw an exception when an assertion fails and continue with the next step after assert statement. This is in the case where our test requires multiple assertions to be executed and we want all of the assertions to be executed first before marking (failing/skipping) the tests. Consider these 2 examples: 1) We're verifying many CSS values of the same element like background-color, font-family, and color in a single test case. element.getAttribute("background-color") element.getCssValue("font-family") element.getCssValue("color") Obviously, if any one of these fails we would like to catch it and mark the test case as fail but that doesn't mean if background-color verification fails it should mark the test case fail with...

At times, we see some weird behavior in your testNG execution and feel that the information displayed is insufficient and would like to see more details. At other times, the output on the console is too verbose and we may want to only see the errors. This is where a verbose attribute can help you- it is used to define the amount of logging to be performed on the console. The verbosity level is 0 to 10, where 10 is most detailed. Once you set it to 10, you'll see that console output will contain information regarding the tests, methods, and listeners, etc. <suite name="Suite" thread-count="5" verbose="10"> Note* You can specify -1 and this will put TestNG in debug mode. The default level is 0. Alternatively, you can set the verbose level through attribute in "maven-surefire-plugin" in pom.xml, as shown in the image. #testNG #automationTesting #verbose # #testAutomation