Angie loves to share her experiences with test automation. She shares her wealth of knowledge by speaking and teaching at software conferences all over the world, as well as writing tutorials and blog posts on angiejones.tech<\/a>.<\/p>\n\n\n\n As a Master Inventor, Angie is known for her innovative and out-of-the-box thinking style which has resulted in more than 25 patented inventions in the US and China. In her spare time, Angie volunteers with Black Girls Code<\/a> to teach coding workshops to young girls in an effort to attract more women and minorities to tech.<\/p>\n\n\n\n Jessica\u2019s work at Microsoft focuses on Azure<\/a>, Containers<\/a>, OSS, and, of course, DevOps<\/a>. Prior to joining Microsoft, she spent over a decade as an IT Consultant \/ Systems Administrator for various corporate and enterprise environments, catering to end users and IT professionals in the San Francisco Bay Area.<\/p>\n\n\n\n Jessica holds two Microsoft Certifications (MCP, MSTS), 3 CompTIA<\/a> certifications (A+, Network+, and Security+), 4 Apple Certifications, and is a former 4-year Microsoft Most Valuable Professional for Windows and Devices for IT.<\/p>\n\n\n\n Angie and Jessica broke the talk into three parts. First, Angie would discuss factors anyone should consider in creating automated tests. Second, Angie and Jessica would demonstrate writing UI tests for a test application.\u00a0 Finally, they would work on adding UI tests to a CI\/CD pipeline.<\/p>\n\n\n\n Let\u2019s get into the meat of it.<\/p>\n\n\n\n Angie first introduced the four factors you need to consider when creating test automation:<\/p>\n\n\n\n She went through each in turn.<\/p>\n\n\n\n Angie started off by making this point:<\/p>\n\n\n\n \u201cWhen your team checks in code, they want to know if the check-in is good as quickly as possible. Meaning, not overnight, not hours from now.\u201d<\/p>\n\n\n\n Angie points out that the talk covers UI tests primarily because lots of engineers struggle with UI testing. However, most of your check-in tests should not be UI tests because they run relatively slowly. From this she referred to the testing pyramid idea<\/p>\n\n\n\n While UI tests take time, Angie points out that they are the only tests showing user experience of your application. So, don\u2019t skimp on UI tests.<\/p>\n\n\n\n Having said that, when UI tests become part of your build, you need to make sure that your build time doesn\u2019t become bogged down with your UI tests. If all your conditions run over 15 minutes, that\u2019s way too long. <\/p>\n\n\n\n To keep your testing to a minimum, Angie suggests running UI tests in parallel. To determine whether or not you need to split up one test into several parallel tests, give yourself a time limit. Let\u2019s say your build needs to complete in five minutes. Once you have a time limit, you can figure out how many parallel tests to set up. Like – with the 15 minute example, you might need to divide into three or more parallel tests.<\/p>\n\n\n\n Next, you need reliable tests. Dependable. Consistent.\u00a0<\/p>\n\n\n\n Unreliable tests interfere with CI processes. False negatives, said Angie, plague your team by making them waste time tracking down errors that don\u2019t exist. False positives, she continues, corrupt your product by permitting the check-in of defective code. And, false positives corrupt your team because bugs found later in the process interfere with team cohesion and team trust. <\/p>\n\n\n\n For every successful CICD team, check-in success serves as the standard for writing quality code. You need reliable tests.<\/p>\n\n\n\n How do you make your tests reliable?<\/p>\n\n\n\n Angie has a suggestion that you make sure your app includes testability – which involves you leaning on your team. If you develop code, grab one of your test counterparts. If you test, sit down with your development team. Take the opportunity to discuss app testability.<\/p>\n\n\n\n What makes an app testable? Identifiers. Any test runner uses identifiers to control the application. And, you can also use identifiers to validate outputs. So, a consistent regime to create identifiers helps you deliver consistency. <\/p>\n\n\n\n If you lack identifiers, you get stuck with CSS Selectors<\/a> or Xpath selectors<\/a>. Those can get messy – especially over time.<\/p>\n\n\n\n Another way to make your app testable, Angie says, requires code that lets your test set initial conditions. If your UI tests depend on certain data values, then you need code to set those values prior to running those tests. Your developers need to create that code – via API or stored procedure – to ensure that the tests always begin with the proper conditions. This setup code can help you create the parallel tests that help your tests run more quickly.<\/p>\n\n\n\n You can also use code to restore conditions after your tests run – leaving the app in the proper state for another test.<\/p>\n\n\n\n Next, Angie said, you need to consider the number of tests you run.<\/p>\n\n\n\n There is a common misconception that you need to automate every possible test condition you can think about, she said. People get into trouble trying to do this in practice.<\/p>\n\n\n\n First, lots of tests increase your test time. And, as Angie said already, you don\u2019t want longer test times.<\/p>\n\n\n\n Second, you end up with low value as well as high-value UI tests. Angie asks a question to help triage her tests:<\/p>\n\n\n\n \u201cWhich test would I want to stop an integration or deployment? If I don’t want this test to stop a deployment, it doesn’t get automated. Or maybe it’s automated, but it’s run like once a day on some other cycle, not on my CICD.\u201d<\/p>\n\n\n\n Angie also asks about the value of the functionality:<\/p>\n\n\n\n \u201cWhich test exercises critical, core functionality? Those are the ones you want in there. Which tests cover areas of my application that have a history of failing? You’re nervous anytime you have to touch that code. You want some tests around that area, too.\u201d<\/p>\n\n\n\n Lastly, Angie asks, which tests provide information already covered by other tests in the pipeline? So many people forget to think about total coverage. They create repetitive tests and leave them in the pipeline. And, as many developers know, a single check-in that triggers multiple failures can do so because it was a single code error that had been tested, and failed, multiple times. <\/p>\n\n\n\n \u201cDon\u2019t be afraid to delete tests,\u201d Angie said. If it\u2019s redundant, get rid of it, and reduce your overall test code maintenance. She talked about how long it took her to become comfortable with deleting tests, but she appreciates the exercise now. <\/p>\n\n\n\n \u201cTest code is code,\u201d Angie said. \u201cYou need to write it with the same rules, the same guidelines, the same care that you would any production code.\u201d<\/p>\n\n\n\n Angie continued, saying that people ask, \u201c\u2018Well, Angie, why do I need to be so rigorous with my test code?\u2019\u201d<\/p>\n\n\n\n Angie made the point that test code monitors production code. In your CICD development, the state of the build depends on test acceptance. If you build sloppy test code, you run the risk of false positives and false negatives.<\/p>\n\n\n\n As your production code changes, your test code must change as well. The sloppier your test code, the more difficult time you will have in test maintenance. <\/p>\n\n\n\n Writing test code with the same care as you write production gives you the best chance to keep your CICD pipeline in fast, consistent delivery. Alternatively, Angie said, if your test code stays a mess, you will have a tendency to avoid code maintenance. Avoiding maintenance will lead to untrustworthy builds. <\/p>\n\n\n\n Next, Angie introduced the application she and Jessica were using for their coding demonstration. The app – a chat app, looks like this:<\/p>\n\n\n\n The welcome screen asks you to enter your username and click \u201cStart Chatting\u201d – the red button. Once you have done so, you\u2019re in the app. Going forward, you enter text and click the \u201cSend\u201d button and it shows up on a chat screen along with your username. Other users can do the same thing.<\/p>\n\n\n\n With this as a starting point, Angie and Jessica began the process of test writing. <\/p>\n\n\n\n Angie and Jessica were on a LiveShare of code, which looked like this:<\/p>\n\n\n\n From here, Angie started building her UI tests for the sign-in functionality. And, because she likes to code in Java, she coded in Java. <\/p>\n\n\n\n All the objects she used were identified in the BaseTests class she inherited.<\/p>\n\n\n\n Her full code to sign-in looked like this:<\/p>\n\n\n\n The test code gest the URL previously defined in the BaseTests class, fills in the username box with \u201cangie\u201d, and clicks the \u201cStart Chatting\u201d button. Finally, Angie added the validateWindow() method inherited from BaseTests, which uses Applitools visual testing to validate the new screen after the Start Chatting button has been clicked.<\/p>\n\n\n\n Next, Angie wrote the code to enter a message, click send message, and validate that the message was on the screen.<\/p>\n\n\n\n The inherited chatPage.sendMessage method both enters the text and clicks the Send Message button. validateWindow() again checks the screen using Applitools.<\/p>\n\n\n\n Are these usable as-is for CICD? Nope.<\/p>\n\n\n\n If we want to run tests in parallel, these tests, as written, block parallel operation, since the enterMessage() depends on the newSession() being run previously.<\/p>\n\n\n\n So solve this, Angie creates a pre-test startSession() that runs before all tests. It includes the first three lines of newSession() which go to the app URL, enter \u201cangie\u201d as the username, and click the \u201cStart Chatting\u201d button. Next, Angie modifies her newSession() test so all it does is the validation.<\/p>\n\n\n\n With this @Before setup, Angie can create independent tests.<\/p>\n\n\n\n Finally, Angie added a multi-user test. In this test, she assumed the @Before gest run, and her new test looked like this:<\/p>\n\n\n\n Here, user \u201cangie\u201d sends the message \u201chello world\u201d. Then, Angie codes the browser to:<\/p>\n\n\n\n Now, it was Jessica\u2019s turn to control the code. <\/p>\n\n\n\n Before she got started coding, Jessica shared her screen from Visual Studio Code<\/a>, to demonstrate the LiveShare feature of VS Code:<\/p>\n\n\n\n Angie and Jessica were working on the same file using LiveShare<\/a>. LiveShare highlights Angie\u2019s cursor on Jessica\u2019s screen. <\/p>\n\n\n\n When Angie selects a block of text, the text gets highlighted on Jessica\u2019s screen.<\/p>\n\n\n\n This extension to Visual Studio Code makes it easy to collaborate on coding projects remotely. It\u2019s available for download on the Visual Studio Code Marketplace<\/a>. It\u2019s great for pair programming when compared with remote screen share.<\/p>\n\n\n\n To begin the discussion of using these tests in CICD, Jessica started describing the environment for running the tests from a developer perspective versus a CICD perspective. A developer might imagine running locally, with IntelliJ or command line opening up browser windows. In contrast, CICD needs to run unattended. So, we need to consider headless.<\/p>\n\n\n\n Jessica showed how she coded for different environments in which she might run her tests.<\/p>\n\n\n\n Her code explains that the environment gets defined by a variable called runWhere, which can equal one of three values:<\/p>\n\n\n\n First, Jessica needed to verify that the testa ran using the local settings.<\/p>\n\n\n\n Jessica set the RUNWHERE variable to \u2018local\u2019 using the command<\/p>\n\n\n\n She had already exported other settings, such as her Applitools API Key, so she can use Applitools.<\/p>\n\n\n\n Since Jessica was already in her visual test folder, she run her standard maven command:<\/p>\n\n\n\n The tests ran as expected with no errors. The test opened up a local browser window and she showed the tests running.<\/p>\n\n\n\n Next, Jessica set up to test her pipeline environment settings. <\/p>\n\n\n\n She changed the RUNWHERE variable using the command:<\/p>\n\n\n\n Again, she executed the same maven tests<\/p>\n\n\n\n With the expectation that the tests would run as expected using her pipeline server, meaning that the tests run without opening a browser window on her local machine.<\/p>\n\n\n\n This is important because whatever CICD pipeline you use – Azure DevOps, Github Actions, Travis CI, or any traditional non-container-based CICD system – will want to use this headless interaction with the browser that keeps the GUI from opening up and possibly throwing an error.<\/p>\n\n\n\n Once these passed, Jessica moved on to testing with containers.<\/p>\n\n\n\n Looking back, the container-based tests used a call to RemoteWebDriver, which in turns called selenium_hub:<\/p>\n\n\n\n Selenium_hub let Jessica spin up whatever browser she wanted.\u00a0 To specify what she wanted, she used a docker-compose file, docker-compose.yaml:<\/p>\n\n\n\n These container-based approaches align with the current use of cloud-native pipelines for CICD. Jessica noted you can use Jenkins<\/a>, Jenkins X<\/a> for Kubernetes<\/a> native, and CodeFresh<\/a>, among others. Jessica decided to show CodeFresh. It\u2019s a CICD pipeline dedicated to Kubernetes and microservices. Every task runs in a container.<\/p>\n\n\n\n Selenium_Hub let Jessica choose to run tests on both a chorme_node and a firefox_node in her container setup. <\/p>\n\n\n\n She simply needed to modify her RUNWHERE variable<\/p>\n\n\n\n However, before running her tests, she needed to spin up her docker-compose<\/a> on her local system. And, because selenium_hub wasn\u2019t something that her system could identify by DNS at that moment (it was running on her local system), she ensured that the selenium_hub running locally would port forward onto her local system\u2019s 127.0.0.1 connection. Once she made these changes, and changed the container definition to use 127.0.0.1:4444, she was ready to run her maven pom.xml file.<\/p>\n\n\n\n When the tests ran successfully, her local validation confirmed that her tests should run in her pipeline of choice.<\/p>\n\n\n\n Jessica pointed out that CICD really comes down to a collection of tasks you would run manually.<\/p>\n\n\n\n After that, Jessica said, we need to automate those tasks in a definition file. Typically, that\u2019s Yaml, unless you really like pain and choose Groovy<\/a> in Jenkins\u2026 (no judgement, she said).<\/p>\n\n\n\n Next, Jessica did a quick look into Azure DevOps.<\/p>\n\n\n\n Inside Azure DevOps, Jessica showed that she had a number of pipelines already written, and she chose the one she had set aside for the project. This pipeline already had three separate stages: <\/p>\n\n\n\n Opening up the build stage shows all the steps contained just within that stage in its 74 seconds of runtime:<\/p>\n\n\n\n Jessica pointed out that this little ChattyBot application is running on a large cluster in Azure. It\u2019s running in Kubernetes, and it\u2019s deployed with Helm<\/a>. The whole build stage includes:<\/p>\n\n\n\n This is a pretty extensive pipeline. Jessica wondered how hard it would be to integrate Angie\u2019s tests into an existing environment.<\/p>\n\n\n\n But, because of the work Jessica had done to make Angie\u2019s tests ready for CICD, it was really easy to add those tests into the deploy workflow.<\/p>\n\n\n\n First, Jessica reviewed the Deploy to Dev stage.<\/p>\n\n\n\n Now, Jessica started doing the work to add Angie\u2019s tests into her existing CICD pipeline. <\/p>\n\n\n\n After the RUNWHERE=container tests finished successfully, Jessica went back into VS Code, where she started inspecting her azure-pipelines.yml file.<\/p>\n\n\n\n Jessica made it clear that she wanted to add the tests everywhere that it made sense prior to promoting code to production:<\/p>\n\n\n\n Jessica reinforced Angie\u2019s earlier points – these UI tests were critical and needed to pass. So, in order to include them in her pipeline, she needed to add them in an order that makes sense.<\/p>\n\n\n\n In her Deploy to Dev pipeline, she added the following:<\/p>\n\n\n\n This script checks to see if the url $hostname is available and gives up if not available after five tries after sleeping 20 seconds. Each try it displays a \u201c.\u201d to show it is working. And, the name \u201cHTTP Check\u201d shows what it is doing. <\/p>\n\n\n\n Now, to add the tests, Jessica needed to capture the environment variable declarations and then run the maven commands. And, as Jessica pointed out, this is where things can become challenging, especially when writing the tests from scratch, because people may not know the syntax. <\/p>\n\n\n\n Now, Jessica moved back from Visual Studio Code to Azure DevOps, where she could also edit an azure-pipelines.yml file directly in the browser.<\/p>\n\n\n\n And, here, on the right side of her screen (I captured it separately) are tasks she can add to her pipeline. The ability to add tasks makes this process really, really simple and eliminates a lot of the errors that can happen when you code by hand.<\/p>\n\n\n\n One of those tasks is an Applitools Build Task that she was able to add by installing an extension.<\/p>\n\n\n\n Just clicking on this Applitools Build Task adds it to the azure_pipelines.yml file. <\/p>\n\n\n\n And, now Jessica wanted to add her maven build task – but instead of doing a bash script, she wanted to use the maven task in Azure DevOps. Finding the task and clicking on it shows all the options for the task.<\/p>\n\n\n\n The values are all defaults. Jessica changed the address for her pom.xml file to visual_tests\/pom.xml (the file location for the test file), set her goal as \u2018test\u2019 and options as \u2018clean test\u2019. She checked everything else, and since it looked okay, she clicked the \u201cAdd\u201d button. The following code got added to her azure-pipelines.yml file.<\/p>\n\n\n\n Jessica copied the Applitools Built Task and Maven task code file back into the azure-pipelines.yml file she was already editing in Visual Studio Code.<\/p>\n\n\n\n Then, she added the environment variables needed to run the tests.\u00a0 This included the Applitools API Key, which is a secret value from Applitools. In this case, Jessica defined this variable in Azure DevOps and could call it by the variable name.<\/p>\n\n\n\n Beyond the Applitools API Key, Jessica also set the RUNWHERE environment variable to \u2018pipeline\u2019 and the TEST_START_PAGE environment variable to the $hostname – same as used elsewhere in her code. All this made her tests dynamic. <\/p>\n\n\n\n The added code reads:<\/p>\n\n\n\n So, now, the tests are ready to commit.<\/p>\n\n\n\n One thing Jessica noted is that LiveShare automatically adds the co-author\u2019s id to the commit whenever two people have jointly worked on code. It\u2019s a cool feature of LiveShare.<\/p>\n\n\n\n So, now that the pipeline code had been added, Jessica wanted to demonstrate that the visual validation with Applitools worked as expected and found visual differences. <\/p>\n\n\n\n Jessica modified the ChattyBot application so that, instead of reading:<\/p>\n\n\n\n \u201cHello, DevOps Days Madrid 2020!!!\u201d<\/p>\n\n\n\n it read:<\/p>\n\n\n\n \u201cHello, awesome webinar attendees!\u201d<\/p>\n\n\n\n She saved the change, double-checked the test code, saw that everything looked right, and pushed the commit.<\/p>\n\n\n\n This kicked off a new build in Azure DevOps. Jessica showed the build underway. She said that, with the visual difference, we expect the Deploy to Dev pipeline to fail. <\/p>\n\n\n\n Since we had time to wait, she showed what happened on an earlier build that she had done just before the webinar. During that build, the Deploy to Dev passed. She was able to show how Azure DevOps seamlessly linked the Applitools dashboard – and, assuming you were logged in, you would see the dashboard screen just by clicking on the Applitools tab.<\/p>\n\n\n\n Here, the green boxes on the Status column show that the tests passed.<\/p>\n\n\n\n Jessica drilled into the enterMessage test to show how the baseline and the new checkpoint compared (even though the comparison passed), just to show the Applitools UI.\u00a0\u00a0<\/p>\n\n\n\n As Jessica said, were any part of this test to be visually different due to color, sizing, text, or any other visual artifact, she could select the region and give it a thumbs-up to approve it as a change (and cause the test to pass), or give it a thumbs-down and inform the dev team of the unexpected difference.<\/p>\n\n\n\n And, she has all this information from within her Azure DevOps build.<\/p>\n\n\n\n Jessica said she gets this question all the time, because not everyone uses AzureDevOps. <\/p>\n\n\n\n You could be using Azure DevOps, TeamCity CI, Octopus Deploy, Jenkins – it doesn\u2019t matter. You\u2019re still going to be organizing tasks that make sense. You will need to run an HTTP check to make sure your site is up and running. You will need to make sure you have access to your environment variables. And, then, finally, you will need to run your maven command-line test. <\/p>\n\n\n\n Jessica jumped into Github Actions, where she had an existing pipeline, and she showed that her deploy step looked identical.<\/p>\n\n\n\n It had an http check, an Applitools Build Task, and a call for Visual Testing. The only difference was that the Applitools Build Task included several lines of bash to export Applitools environment variables.<\/p>\n\n\n\n The one extra step she added, just as a sanity check, was to set the JDK version.<\/p>\n\n\n\n And, while she was in Github Actions, she referred back to the container scenario. She noted the challenges with spinning up Docker Compose and services. For this reason, when looking at container tests, she pointed to CodeFresh, which is Kubernetes-native.<\/p>\n\n\n\n Inside her CodeFresh pipelines, everything runs in a container.<\/p>\n\n\n\n As she pointed out, by running on CodeFresh, she didn\u2019t need a huge server to handle everything. Each container handled just what it needed to handle. Spinning up Docker Compose just requires docker. She needed just jFrog for her Artifactory image. Helm lint – again, just what she needed.<\/p>\n\n\n\n The image above shows the pipelines before adding the visual tests. The below image shows the Deploy Dev pipeline with the same three additions.<\/p>\n\n\n\n There\u2019s the HTTP check, the Applitools Build Task, and Running Visual Tests.<\/p>\n\n\n\n The only difference really is that the visual tests ran alongside services that were spinning up alongside the test.<\/p>\n\n\n\n This is really easy to do in your codefresh.yml file, and the syntax looks a lot like Docker Compose.<\/p>\n\n\n\n Back in Azure DevOps, Jessica checked in on her Deploy to Dev step.\u00a0 She already knew there was a problem from her Slack notifications.\u00a0\u00a0<\/p>\n\n\n\n The error report showed that the visual tests all failed.<\/p>\n\n\n\n Clicking on the Applitools tab, she saw the following.<\/p>\n\n\n\n All three tests showed as unresolved.\u00a0 Clicking in to the multiPersonChat test, Jessica saw this:<\/p>\n\n\n\n Sure enough, the text change from \u201cHello, DevOps Days Madrid 2020!!!\u201d to \u201cHello, awesome webinar attendees!\u201d caused a difference. We totally expected this difference, and we would find that this difference had also shown up in the other tests.<\/p>\n\n\n\n The change may not have been a behavioral change expected in your tests, so you may or may not have thought to test for the \u201cHello\u2026\u201d text or check for its modification. Applitools makes it easy to capture any visual difference.<\/p>\n\n\n\n Jessica didn\u2019t go through this, but one feature in Applitools is the ability to use Auto Maintenance. With Auto Maintenance, if Jessica had approved the change on this first page, she could automatically approve identical changes on other pages. So, if this was an intended change, it would go from \u201cUnresolved\u201d to \u201cPassed\u201d on all the pages where the change had been observed.<\/p>\n\n\n\n Jessica handed back presentation to Angie, who shared Jessica\u2019s link for code from the webinar:<\/p>\n\n\n\n All the code from Angie and Jessica\u2019s demo can be downloaded from:<\/p>\n\n\n\n https:\/\/aka.ms\/jldeen\/applitools-webinar<\/a><\/a><\/p>\n\n\n\n Happy Testing!<\/p>\n\n\n\n What does it take to add UI tests in your CICD pipelines? On March 12, Angie Jones, Senior Developer Advocate at Applitools, sat down with Jessica Deen, Senior Cloud Advocate…<\/p>\n","protected":false},"author":77,"featured_media":17914,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[10004],"tags":[10199,12782,13943,12691,10052,10086,12956,10139,12688,12690,12686],"acf":[],"yoast_head":"\nThe Talk<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-1-1024x572.png\")
<\/figure>\n\n\n\nFour Factors to Consider in Automated Tests<\/h2>\n\n\n\n
\n
Speed<\/h3>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-2-1024x574.png\")
<\/figure>\n\n\n\n\n
Reliability<\/h3>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-3-1024x575.png\")
<\/figure>\n\n\n\nQuantity<\/h3>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-4-1024x575.png\")
<\/figure>\n\n\n\nMaintenance<\/h3>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-5-1024x572.png\")
<\/figure>\n\n\n\nWriting UI Tests – Introduction<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-6.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-7.png\")
<\/figure>\n\n\n\nWriting UI Tests – Coding Tests<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-8-1024x622.png\")
<\/figure>\n\n\n\npublic class ChattyBotTests extends BaseTests {\n private ChatPage chatPage:\n\n @Test\n public void newSession(){\n driver.get(appUrl);\n homePage.enterUsername(\"angie\");\n chatPage = homePage.clickStartChatting();\n validateWindow();\n }<\/pre>\n\n\n\n @Test\n public void enterMessage(){\n chatPage.sendMessage(\"hello world\");\n validateWindow():\n }<\/pre>\n\n\n\nCoding Pre-Test Setup<\/h3>\n\n\n\n
@Before\n public void startSession(){\n driver.get(appUrl);\n homePage.enterUsername(\"angie\");\n chatPage = homePage.clickStartChatting();\n }\n\n @Test\n public void newSession(){\n validateWindow();\n }<\/pre>\n\n\n\nAdding Multi-User Test<\/h3>\n\n\n\n
@Test\n public void multiPersonChat(){\n\n \/\/Angie sends a message\n chatPage.sendMessage(\u201chello world\u201d);\n\n \/\/Jessica sends a message\n WindowUtils.openNewTab(driver, appUrl);\n homePage.enterUsername(\"jessica\");\n chatPage = homePage.clickStartChatting();\n chatPage.sendMessage(\"goodbye world\");\n WindowUtils.switchToTab(driver, 1);\n validateWindow();\n }<\/pre>\n\n\n\n\n
Integrating UI Tests Into CICD<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-9.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-10.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-11.png\")
<\/figure>\n\n\n\n\n
Testing Locally<\/h3>\n\n\n\n
export RUNWHERE=local<\/pre>\n\n\n\n
mvn -f visual_tests\/pom.xml clean test<\/pre>\n\n\n\n
Testing Pipeline<\/h3>\n\n\n\n
export RUNWHERE=pipeline<\/pre>\n\n\n\n
mvn -f visual_tests\/pom.xml clean test<\/pre>\n\n\n\n
Testing Containers<\/h3>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-12.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-13.png\")
<\/figure>\n\n\n\nexport RUNWHERE=container<\/pre>\n\n\n\n
Looking at Azure DevOps<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-14.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-15.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-16.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-17.png\")
<\/figure>\n\n\n\nAdding UI Tests in Your CICD Pipeline<\/h2>\n\n\n\n
\n
- bash:
# run check to see when $(hostname) is available
attempt_counter=0
max_attempts=5
until $(curl --output \/dev\/null --silent --head --fail https:\/\/\u201d$(hostname)\u201d\/); do
if [ ${attempt_counter} -eq ${max_attempts} ]; then
echo \u201cMax attempts reached\u201d
exit 1
fi
printf \u201c.\u201d
attempt_counter=$((attempt_counter+1))
sleep 20
done
displayName: HTTP Check<\/pre>\n\n\n\nEditing the azure-pipelines.yml in Azure DevOps<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-18-1024x685.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-19.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-20.png\")
<\/figure>\n\n\n\n - task: Maven
inputs:
mavenPomFile: \u2018visual_tests\/pom.xml\u2019
goals: 'test'
options: 'clean test'
publishJUnitResults: true
testResultsFiles: '**\/surefire-report\/TEST-*.xml'
javaHomeOption: 'JDKVersion'
mavenVersionOption: 'Default'
mavenAuthenticationFeed: false
effectivePomSkip: false
sonarQubeRunAnalysis: false<\/pre>\n\n\n\nGoing Back To The Test Code<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-21.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-22.png\")
<\/figure>\n\n\n\n env:
APPLITOOLSAPIKEY: $APPLITOOLS_API_KEY
RUNWHERE: pipeline
TEST_START_PAGE: https:\/\/($hostname)\/<\/pre>\n\n\n\nVerifying That UI Tests Work In CICD<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-23-1024x580.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-24-1024x459.png\")
<\/figure>\n\n\n\nWhat If I Don\u2019t Use Azure DevOps?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-25-1024x826.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-26-1024x516.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-27.png\")
<\/figure>\n\n\n\nSeeing the Visual Failure<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-28.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-29.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-30-1024x462.png\")
<\/figure>\n\n\n\nSumming Up<\/h2>\n\n\n\n
![\"\"](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2023\/12\/ui-tests-cicd-31-1024x576.png\")
<\/figure>\n\n\n\nFor More Information<\/h2>\n\n\n\n
\n