Home / IT & Computer Science / Business Technology / Microsoft Future Ready: Continuous Integration Implementation / Test Automation with Selenium
Test Automation with Selenium
.
Hello, and welcome back. In this video, we’re going to talk about config transforms in a release pipeline. Now, when you start on this journey of deployment automation, you start to look at the application-specific items that are related to the environment that you’re deploying to. Now, if you’re only doing a one-off deployment or maybe two deployments in a day, it’s still OK to manually transform the config. But I must warn you that manually transforming or updating the config file per the environment introduces an element of risk, where you may accidentally forget to update the config file. And it may point to another test environment database.
And you may start to get erroneous outputs in your application wondering, why has this suddenly stopped working? Only to figure out that it was a config value update that was kept as part of the rollout of the application on the test environment. Other scenarios where it can impact you is I’ve seen teams taking backup of applications from production to set it up on test environments, and it can be very expensive if then you forget to update the connection string. And provided there is no fence of permissions, you could then accidentally end up writing into your production systems from your test systems. I’ve seen that happen in customer sites where there isn’t fencing in place between test environments and production.
Taking a backup, not having an automated process to sanitise the environment can cause these issues. So both from a speed point of view as well as from a resilience point of view, it makes sense to have an automated process for running the conflict transformation. Now, there is a full course coming on the edX library very soon, which we’ll talk about, conflict management, not only from an application point of view, but from a server point of view, an overall configuration management. In this video, we’re very much just going to focus on the application configuration transformation and that to look at simple things like connection strings, things like log folder locations.
These are settings that you have in app.config files and web.config files that you just want to transform as you roll these out into test environments. This video is very much focused on the deployment automation side of things, more specifically to the provisioning and the deployment of the application. OK, so let’s get into a demo. So I’ve got the same pipeline that we have been setting up for Summit Master. And in this pipeline, I’ve added a new task called the replace tokens task. Now, you can search for this task called replace. And if this doesn’t show up here, and the chances are it won’t, it’s because it’s not a Microsoft-provided extension.
It’s an open-source extension, so you have to go into the marketplace and search for replace token and then instal it for your instance of Visual Studio Team Services. You’d see that you’re spoiled for choice here, where there are so many tasks available for tokenization. Pretty much all of them, give and take, do the same thing but have different implementations. So I found this one quite useful. I found the one provided by Colin quite useful as well. In essence, one gives you a regex format that is capable of scanning all the config files across your application and then using that regex format to identify if it has any matches.
And then it looks at the variables, either the environment variables or the application variables, that have the same matching name to one that is being tokenized. And then where there is alignment, it does the replacement. Let’s see this in action. So within the pipeline, now that we have the task, let’s click on the task. We have an option to say, what is it that we want to transform? Now, in this case, I’m transforming an XML file. And I’ll explain why. But you could have an option to transform a config file, whether an app.config– you could make it quite loose with wildcard characters.
Or you could make it very specific and generic, very specific to a one specific configuration file that you want to update. And again, you can clone this multiple times if there are multiple config files across multiple solutions that you need updating. Now, as I’m doing this in the build, I’m running this step before I’m creating the package, which means I’m updating the configuration for sanitization or for packaging. But you could run the same operation in a release pipeline and have the application roll the release out and then run this task to validate the configuration or update the configuration.
All it does behind the scenes is look for the config file, match the regex, look for the variable names, match those variable names to ones you have in the build, and then simply replace the value. And because the build infrastructure allows you to specify variable names that can be encrypted, it just sits very nicely together, where you don’t have to manage passwords in a separate password save or in separate config files or Excel spreadsheets. So if we look at this here, it also preserves the encoding of the file, which I think is quite good.
But you also have the option of specifying exclusively what the encoding should be if this is something you want to enforce in your config files as well. And then this is the format in the Advanced section that I’m looking for. I’m saying, in the config file, if you find a similar format, then that’s a valid candidate I want to have replaced as part of the config transformation. Now, I need to make one additional change to the code base. And I’ll show you one. So if we navigate back to the code base and open up the Summit.Web project, we have to add an XML file called the Parameters file.
Now, the Parameters file is just a collection of parameter values that you want updated against your config file. And it supports XPath. So I’m basically saying here, one of the parameters that I want to replace is the name of the environment. This is a description of what that variable is. The default value is this. Now, you can see referring back to the task I have is I’m using the same regex format. I’m saying, parentheses, hash, underscore, underscore, and then the name of the parameter. So when the task searches and finds this XML file, it will say, OK, there’s a match. As long as I can find a variable called ENVIRONMENT, I’ll simply replace its value for this whole string.
And then that’s how the transformation is done behind the scenes. The second thing I have is a log file location. Again, I’m using the same steps here. I’m saying, this is the default value. It’s an XML file type, and this is the exact match as to where it needs to be replaced. So I’m saying /configuration/appsettings/add key=’Log’, and this is the value. So if we go back into the web.config, you’d see the XPath matches to this. We’re saying, configuration, appSettings, Log, and this is the value that needs to be replaced. So it’s quite a constructive way where you don’t have to overload your web config directly. You can still have local values for your local machine.
You can even use extensions like SlowCheetah, which are available within Visual Studio, that allow you to use the configuration-driven config views that you have, part of the solution configuration like for debug for release or the others you create. But then at the same time, it’s abstracting the override into a separate parameter file that the build can override for you, that the release can override for you. And as part of Web Deploy, Web Deploy is capable well enough to take the parameter file and do the substitution for you through the build and the release process.
So having specified the parameters in the parameter file and having specified the actual parameters to be replaced in the web.config file, I’m going to go back into the build and quickly execute the build.
Now, we’ll let it run. This may take a few minutes to complete.
Since most of my agents are running in DevTest Labs, I have an auto-shutdown schedule set up there. So they all have been switched off. So instead of running it on my own private agents, I will run this on the Visual Studio-hosted agent in the Microsoft cloud.
Right, so the build’s complete here. If we click on the output here and navigate to the artefact section, click on Explore. And then navigate down to the SetParameters.xml, and let’s download this file.
Let’s open this up. There you go. You can see that the values have been replaced here. And let’s put this in context. Take a step back and look at the build setup that we had here. So as part of this step, which runs before the build, we’re saying, go look for any XML file. And within that XML file, search for the pattern which is specified here. And then wherever you find this pattern, look for the name match of any variables. And if we look in the Variables section, I’ve defined two variables– ENVIRONMENT and LOG. And they both have a value here. And if we go back into the code and check our Web.config, we have Environment and Log.
And in the parameter file, it’s exactly looking for ENVIRONMENT. And it’s exactly looking for LOG specified within the regex pattern that we’ve specified, and that’s how it applies the transformation. Now, now that it’s made the update to this specific XML file, the SetParameter.xml, it’s the SetParameter.xml file that gets run as part of the web deploy using MSBuild. And it will during the deployment process look at the values within the SetParameters, and it will search for those values within the web package and do the transformation for you. This is one of the ways of doing it. I’m not saying this is the ultimate way of doing it.
You could introduce the regex format directly in your config file and have it replaced there. You could run it a step before the web package gets created. You could run it a step after the web package gets created. But all in all, this is one of the ways of doing it. And regardless of the way you do it, it’s important that you transform your config files as part of your build or release step, just to ensure the sanity and the speed within your continuous delivery process.
So far in this course, you have created an automated build process that is deploying into the cloud. The next step in the process is testing. And with an automated build process, you ideally want an automated testing process as well.
In this step, we will discuss what test automation and Selenium is and how you can use Selenium for test automation.
What is Test Automation?
Test automation is the practice of running tests automatically, managing test data and utilising results to improve software quality. It is primarily a quality assurance measure, but its activities involve the commitment of the entire software production team.
There are typically four levels or quadrants of testing:
- Technology-facing tests that support the team, including, Unit tests, API tests, Web Services testing, and Component Tests.
- Business-facing tests that support the team, such as, Functional Testing, Story Tests, Prototypes, and Simulations.
- Business-facing tests that critique the product, for example, Exploratory Testing, Scenario-based Testing, Usability Testing, User Acceptance Testing, and Alpha/Beta testing.
- Technology-facing tests that critique the product, which covers tests such as Performance & Load Testing, Security Testing, and ‘*ility’ testing – Stability, Reliability, Scalability, Maintainability, Compatibility, etc.
Selenium
Selenium is one of the popular open-source frameworks available in the market for test automation.
Selenium is used to perform user interface testing by executing scripted actions against browser DOM. It is most commonly used for functional testing to verify that key functionality continues to work after the latest build gets deployed, but it can also be used for unit and load testing.
PhantomJS is a headless web driver that automates browser testing in cloud environments in an unattended manner. By plugging Selenium into our CI / CD pipeline, we enable quick feedback to developers when web UI issues are detected.
For more information on using Selenium with VSTS, see https://www.visualstudio.com/en-us/docs/test/continuous-testing/getting-started/continuous-test-selenium.
For more information on Selenium, see http://www.seleniumhq.org/docs/01_introducing_selenium.jsp.
Adding a Selenium Test
To add a Selenium test, you need to create a new project by right-clicking your solution and selecting Add. When you have added a New Project, navigate to the test section. In this section, you can select any unit testing project that is available.
Now that you have selected a unit test project, you can navigate to your NuGet feed. Within NuGet, you can search for Selenium. Although the Selenium package might already be added, you may have to add the Selenium WebDriver and some other optional drivers. There will be some settings you have to add depending on the test you have created.
The next step is to create and initialise your tests, and once that is completed, you can commit your tests in the source control. Once you queue your test up in your build and the test execution is complete, a report is generated that shows you a full test execution summary.
This article is from the online course:
Microsoft Future Ready: Continuous Integration Implementation
Created by
This article is from the free online
Microsoft Future Ready: Continuous Integration Implementation
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
