My Testing Thoughts

Implementation of Selenium Manager across bindings is one of the key features of the Selenium 4.6.0 release. The Selenium project wants to simplify how we all set up our environment. Setting up browser drivers has been for many years a task that we need to perform all the time.  To run a Selenium test with Selenium 4.6.0, we only need to have Chrome, Firefox, or Edge installed. If you already have browser drivers installed, this feature will be ignored.  Just add 4.6.0 Selenium dependency: <dependency>     <groupId>org.seleniumhq.selenium</groupId>     <artifactId>selenium-java</artifactId>     <version>4.6.0</version> </dependency> And as is use: WebDriver driver = new ChromeDriver(); Also, future releases of Selenium Manager will eventually even download browsers if necessary. :) Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

To access Shadow DOM elements in Selenium 4 with Chromium browsers (Microsoft Edge and Google Chrome) version 96 or greater, we can use the shadow root method: WebElement  shadowIdContent  = driver.findElement(By.cssSelector("#shadow_host")) .getShadowRoot() .findElement(By.cssSelector("#shadow_content")); What happened in v96 is that Chromium has made its shadow root values compliant with the updated W3C WebDriver specification, which now includes definitions for getting an element’s shadow root and locating elements in a shadow root.   I found this excellent video for the same : https://youtu.be/-uMLqBO2x7c Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

 Comparison of maven-surefire-plugin and maven-failsafe-plugin: References :     Maven Failsafe Plugin: https://maven.apache.org/surefire/maven-failsafe-plugin/index.html      Maven Surefire Plugin: https://maven.apache.org/surefire/maven-surefire-plugin/index.html   Someone asked me then what is the advantage of using one over the another. The advantage is the way they fail: Failsafe > runs all the integration tests, but if any tests fail during the integration-test phase, the plugin does not fail the build immediately. It still executes the post-integration-test phase. Therefore we can still perform any cleanup and environment tear-down as part of the post-integration-test phase. The subsequent verify phase of the build process reports any test failures. Surefire > It binds with the test phase, in case of any test failures, the build fails, and no further phases execute during the build process.

  A simple, extendable, and nice alerting tool to forward the test results from your CI/CD environment to different entities like teams or Slack: https://test-results-reporter.github.io/ It publishes test results from test frameworks like JUnit, TestNG, and xUnit.  GitHub link: https://github.com/test-results-reporter/reporter #alerts #automation #reporting #slack #teams #webhooks Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

Steps to follow: Microsoft Teams WebHook: Follow this  https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook to create a webhook. Capture the  URL you will get from Step # 5 from the above article for Posting the Results in MS teams. Select a design from https://adaptivecards.io/samples/ or you can take the one that I created here:  https://github.com/dgambhir01/AdaptiveCards/blob/main/src/main/java/listeners/ResultBuilder.java Now implement the Builder Class and a POJO Class. Sample code:  https://github.com/dgambhir01/AdaptiveCards/blob/main/src/main/java/listeners/CardBodyStructure.java Last but not least add a Listener Class to send Results on Finish. Sample code:  https://github.com/dgambhir01/AdaptiveCards/blob/main/src/main/java/listeners/ResultListener.java Now you can add the above TestNG Listener to your TestNG XML File and run your test cases.  After the Execution, you should see your t...

  Of course, there are many ways to tackle it but I have mentioned below one of the ways where you can use the given code in the Tests tab of the postman. Unfortunately, in some of the lower environments, there can be a situation where you request fail at times due to infra issues, timeouts, etc., so in that case, this can be super helpful: var notExpectedText = 'Failed'; var maxTries = 3; var pauseBetweenTries = 5000; if (!pm.environment.get("tries")) {     pm.environment.set("tries", 1); } if ((pm.expect(pm.response.text()).to.not.include(notExpectedText)) && (pm.environment.get("tries") < maxTries)) {      var tries = parseInt(pm.environment.get("tries"), 10);      pm.environment.set("tries", tries + 1);      setTimeout(function() {}, pauseBetweenTries);      postman.setNextRequest('PaymentService'); //here you should give your request name that you want to retry on failure  } else {   ...

Azure DevOps offers a fantastic set of REST APIs which allows you to extract and operate data within Azure DevOps by sending an HTTP request to a specific service. It is up to you how you want to call these APIs i.e., using Postman if you are not a fan of coding much or you can use RestAssured, RestSharp libraries if you can write code. I am using Postman here to execute these APIs; all the Azure DevOps Rest APIs expect you to follow these things: 1)    Provide the PAT (Personal Access Token) in the Authorization  tab: o   Type : Basic Auth o   Username : leave it blank o   Password : Enter your PAT Note* Here is how you can create a PAT: https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows#create-personal-access-tokens-to-authenticate-access 2)     Send the request o Select the HTTP Method (Get, Post...