Unable to Pass Selenium tests within Azure Pipeline - c#

I am trying to build out UI test cases in our CI/CD build pipeline within Azure Devops and I can't seem to workaround a basic use case where we route to one of our internal web pages landing screen, and verify a Div with a Selector exists.
[Theory]
[InlineData("Chrome")]
public void TestFindElementByID(string browser)
{
var driver = SetupDriver(browser);
try
{
driver.Navigate().GoToUrl(TestConfig.WebURL);
WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10));
IWebElement element = wait.Until(ExpectedConditions.ElementIsVisible(By.Id("mainRepDiv")));
//Thread.Sleep(2500);
//IWebElement element = driver.FindElement(By.Id("mainRepDiv"));
Assert.True(element != null);
}
catch (Exception ex)
{
}
finally
{
driver.Quit();
}
}
In my web page, I have a basic div that I just want to see that it exists once the chromedriver navigates to the URL.
Element To Check
And here is a log of the Azure Pipeline failing on this test.
Pipeline Log
I do have an additional test that just asserts that the Browser is able to go to the URL, and the URL is in fact what I routed to, and that test passes.
driver.Navigate().GoToUrl(TestConfig.URL);
Assert.True(driver != null);
Assert.True(driver.Url.ToLower() == TestConfig.URL.ToLower());
There also some layers that likely are making this more difficult such as
The Azure Pipeline is running off a Self-hosted agent.
This self hosted agent is also the same server that is running the application were trying to test against.
There is OS level Security that shows up if you route to it normally, however as the Windows Server that is running the application would have a valid credential to the browser, it should bypass this dialog.
So things I have tried so far:
Various ways of actually selecting the Element incase that was off, such as By ID that is shown, or by XPath as well.
Using the Thread.Sleep() or the WebDriver Wait commands to determine if it was a page load.
Implementing AutoIT Process that will run in the event there is in fact an OS popup that displays, so I can prefill the Admin Username/Password credentials incase it actually is not getting there.
Running the unit test locally on my client PC, publishing the code to the Server, running the code from the application server directly and verifying it works there as well.
So I'm a bit at a loss what to check on regarding the Azure Pipeline build itself and why the ChromeDriver is unable to pass this test.
Finally - if this is also helpful, here is a screenshot of the YML file pertaining to the Tasks.
- task: VSTest#2
displayName: "Run UI Tests"
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
**\Project.Test.UI.dll
!**\*TestAdapter.dll
!**\obj\**
searchFolder: '$(System.DefaultWorkingDirectory)'
uiTests: true

Unable to Pass Selenium tests within Azure Pipeline
Please make sure your private agent run as an interactive process.
According to the document Interactive vs. service:
You can run your self-hosted agent as either a service or an
interactive process. After you've configured the agent, we recommend
you first try it in interactive mode to make sure it works. Then, for
production use, we recommend you run the agent in one of the following
modes so that it reliably remains in a running state.
As an interactive process with auto-logon enabled. In some cases, you might need to run the agent interactively for production use -
such as to run UI tests. When the agent is configured to run in this
mode, the screen saver is also disabled. Some domain policies may
prevent you from enabling auto-logon or disabling the screen saver. In
such cases, you may need to seek an exemption from the domain policy,
or run the agent on a workgroup computer where the domain policies do
not apply.
So, if your agent not run as interactive mode, please configure a another agent in interactive mode to test this issue.

Related

Selenium ChromeDriver returns 403 errors on build server

We've created a Selenium test project that starts the (ASP.NET) web application and runs a couple of tests using the ChromeDriver. Locally this all runs fine (in headless and non-headless mode).
But on the build server (using an Azure DevOps agent) this fails without ever starting the tests. It looks like it fails when starting the ChromeDriver: the driver starts, but then it's immediately followed by 403 errors. It never gets to the part where it actually loads a webpage.
Any ideas where to look?
Answering my own question to document possible solutions.
After some rigorous investigation (which included using the source code to get to the bottom of things) we found out that the proxy server somehow got in the way. It turned out that the ChromeDriver tries to communicate over a local port (e.g. http://localhost:12345), which was redirected through the proxy server. This failed with a 403 error.
This gave us a lead on possible solutions. First we tried to use the .proxybypass file to exclude localhost addresses. This didn't work -- it turns out that this proxy bypass only works for https requests. And the ChromeDriver control commands are sent over http :-(
We then made sure that no proxy was used in our test code. We did this with the following lines:
var options = new ChromeOptions();
options.AddArgument("--no-sandbox");
options.AddArgument("headless");
options.AddArgument("ignore-certificate-errors");
options.Proxy = new Proxy()
{
Kind = ProxyKind.Direct
};
var driver = new ChromeDriver(options);
In addition to these settings (note that some arguments were added to solve other issues and might not apply to your own situation), we also disabled the proxy for other requests:
WebRequest.DefaultWebProxy = null;
HttpClient.DefaultProxy = new WebProxy()
{
BypassProxyOnLocal = true,
};
This allowed our tests to finally run on the build server without the 403 errors.
One last remark (which might be obvious) is to always run your tests in non-headless mode if you encounter any issues. This allowed us to see the "invalid certificate error" which would otherwise be hidden.

Selenium tests open IE in background on TFS build server

we are trying to use Selenium for testing our MVC application. On localhost in VS2017 , it´s running correct, the tests open IE, run the test and then close the IE.
On TFS build server, the tests start IE somehow on background (in Task manager I see two iexplorer.exe processes), but the window of IE is not visible. The tests find elements, but they are not able to write text in textbox, always get error like "Element cannot be interacted with via the keyboard because it is not focusable"
Localy I run Win10 and IE11, TFS build server run Windows Server 2012 R2 and IE11 .
//initialize driver in test constructor
InternetExplorerOptions options = new InternetExplorerOptions();
options.IntroduceInstabilityByIgnoringProtectedModeSettings = true;
options.RequireWindowFocus = true;
driver = new InternetExplorerDriver(options);
driver.Manage().Window.Maximize();
//test itself
driver.Navigate().GoToUrl(appURL);
var x = driver.FindElement(By.Id("FiltrADuvodDotazu_DuvodDotazu"));
x.SendKeys("Automatizovaný test"); //here I get error
Is there way to run IE visibly, so the tests can interact with it?
I guess your agent run as a service and this is the reason the tests run on "headless mode" (and IE not supports it, like mentioned in the comments).
To solve it you need to configure the agent as an interactive process with auto-logon enabled.
When configuring the agent, select 'No' when prompted to run as a service. subsequent steps then allow you to configure the agent with auto-logon.
More info you can find here.

Selenium IE 11 test on Jenkins Master Server Using nunit3-console.exe

I have a Selenium IE 11 test written in C# that runs perfectly when run locally in Debug or Release. this code is deployed to a Win 10 box with Jenkins (NO SLAVES). The Jenkins "Build" is configured to build the code, copy the test.dll to a folder and then call nunit3-console.exe to run the test. the Jenkins Service is also configured with a Domain User Account as a Service Logon Account.
I can logon to the win 10 box as the (Jenkins) domain user, and open a cmd window and run the following with no problem at all
C:\Program Files (x86)\Jenkins\workspace\Prod Login>"C:\Program Files
(x86)\NUnit.org\nunit-console\nunit3-console.exe" C:\Prod
Login\Tests\bin\Debug\Tests.dll
but if you try to "Build" the solution via Jenkins Web UI, it has a problem during the Nunit test finding some elements after it does a few clicks and a submit.
I know the IE configuration is rock solid like I said the test runs fine in a command window when logged in as the (Jenkins) Domain account
here is the error I get:
Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException :
Assert.Fail failed. ProcessError* By.XPath:
//input[#placeholder='Username'], Following element not found:
By.XPath: //input[#placeholder='Username'], Timed out after 75
seconds;
again I know its not the locator, it works with By.Id or By.Xpath in the command window, AND my Chrome, and Firefox test with the SAME code base just a different WebDriver all work.
I can't help but think it has something to do with the Identity that's being used by Jenkins and or Nunit
any help is greatly appreciated!!!
** UPDATE
I just tried to configure a Jenkins "Slave" with the service account
running as the Jenkins Domain user, no luck still...
I am unable to post just a comment, but I have a debug suggestion. I know what you are saying with "the selector works fine", so I am not suggesting that the selector is wrong in any way. However, I do suggest having the test spew the page source just before the failing command. Driver.PageSource. And post it somewhere you can get to it.
That way, you can identify that the driver definitely sees the elements in the DOM that it has available to it.
This will help eliminate a whole slew of potential problems. There is always the possibility that the driver is simply not seeing the html that these selectors would point to, even though we can see it with our own two eyes.

Unable to start an NServiceBus Windows Service

Problem Description
I have a Windows service which is hosting an NServiceBus endpoint in NServiceBus.Host.exe.
The binaries are deployed to c:\inetpub\bus\services\myService folder on the server.
A DSC script makes sure the Windows service is created/exists on the server, with the "path to executable" property of the service set to "c:\inetpub\bus\services\myService´NServiceBus.Host.exe" -service NServicebus.Production.
Note! The -service switch is added when installing the service by using the built-in NServiceBus.Host.exe /install parameter, which is why I added it to the Windows service executable path in the DSC script.
Now, when I try to start the service manually on the server, it yields the following error message
Windows could not start the <service name> service on the Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion.
Debugging Steps
I have looked through the event log and the following two error messages sticks out:
NServiceBust.Host.exe error:
Application: NServiceBus.Host.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info:
Topshelf.Exceptions.ConfigurationException
at Topshelf.Internal.Actions.RunAsServiceAction.Do(Topshelf.Configuration.IRunConfiguration)
at Topshelf.Runner.Host(Topshelf.Configuration.IRunConfiguration, System.String[])
at NServiceBus.Host.Program.Main(System.String[])
Local Activation permission error:
The application-specific permission settings do not grant Local
Activation permission for the COM Server application with CLSID
{D63B10C5-BB46-4990-A94F-E40B9D520160}
and APPID
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
to the user <my_service_account_user> SID (<service_account_SID>) from
address LocalHost (Using LRPC) running in the application container
Unavailable SID (Unavailable). This security permission can be modified
using the Component Services administrative tool.`
Note! The error above only occurs once, i.e. the first time I try to start the service. It does not appear again in the event log for any subsequent attempts of starting the service.
What I have done so far:
Tried the suggestions in a closely related post here on SO, none of which were working.
Tried to install the service by using using the NServiceBus.Host.exe /install parameter. In this case, the service name is created with its name on the following format: MyService.EndpointConfig_v1.0.0.0. Using this approach, the service starts successfully without any error message
Stopping the service and then try to start the service created by the DSC script (with a different name) => success
Removing the service created by NServiceBus and then trying to start the DSC-created service again => failure
Tried granting the service account used for logon when running the service various privileges (neither of which yielded any success), among others:
Membership in the Administrators group
Membership in the Performance Log Users group
Full DCOM permissions via "Launch and Activation Permissions" in dcomcnfg
Tried running c:\inetpub\bus\services\myService´NServiceBus.Host.exe NServicebus.Production from the CLI => success
Code
My Init() method for the service looks like this:
namespace MyService
{
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server, IWantCustomLogging, IWantCustomInitialization
{
public void Init()
{
Directory.SetCurrentDirectory(System.AppDomain.CurrentDomain.BaseDirectory);
SetLoggingLibrary.Log4Net(() => XmlConfigurator.Configure(File.OpenRead(#"log4net.config")));
GlobalContext.Properties["Hostname"] = Dns.GetHostName();
GlobalContext.Properties["Service"] = typeof(EndpointConfig).Namespace;
var container = new WindsorContainer(new XmlInterpreter());
Configure.With()
.CastleWindsorBuilder(container)
.XmlSerializer()
.MsmqTransport()
.IsTransactional(true)
.PurgeOnStartup(false)
.IsolationLevel(System.Transactions.IsolationLevel.RepeatableRead);
var connectionString = ConfigurationManager.ConnectionStrings["<some_conn_string>"].ConnectionString;
container.Register(
Component.For<IDatabaseProvider>()
.ImplementedBy<DatabaseProvider>()
.DependsOn(Property.ForKey("connectionString").Eq(connectionString)));
}
}
}
Theory
When installing the service using /install I assume that NServiceBus.Host.exe does some black magic under the hood - e.g. grants some necessary permissions - to make the service able to start.
Note! On the server, the latest version of NServiceBus is installed (v6.x). However, in my solution/service project version 2.x is used (please, do not ask if I can upgrade - unfortunately, that is not an option).
Appreciate any help I can get, as I am running out of ideas.
EDIT 1
I was asked why I can't just use the /install parameter of NServiceBus and be happy with that. The answer to that is that I could (and, actually, I currently am).
The reason I have still posted this question is split:
I wish to understand why one of two seemingly equivalent approaches fails
I am not completely happy with using the /install parameter. The reason? It boils down to a "chicken or the egg" problem. I use Powershell DSC to provision servers in Azure and I believe that ensuring that Windows Services exists on the server is the responsibility of DSC. However, the first time a server is provisioned the services cannot exist unless I script their creation with DSC, and point the executable path to where the service binaries will be deployed whenever that happens. The other alternative is to skip service creation in DSC, and run the NServiceBus.Host.exe /install as a part of the service/application deployment script instead. Obviously, deployment cannot happen until after a server has been provisioned. Thus, it requires the Windows Service part of the DSC script being stripped down to e.g. merely ensuring the service exist - a verification which will fail until a first time deployment of the application has been performed.

VMWare vix api - not logging in into Vitual machine

While powering up the virtual machine:
var virtualMachine = host.Open("myVM.vmx");
virtualMachine.PowerOn();
virtualMachine.LoginInGuest("Administrator", "myPass");
everything gets stuck in the log in screen of the VM. Is it possible somehow to start up the VM, and have the GUI loaded and ready, because automated tests require the GUI of the application to be present so the tests can fire off.
pass VIX_LOGIN_IN_GUEST_REQUIRE_INTERACTIVE_ENVIRONMENT to LoginInGuest.
See the remarks: https://www.vmware.com/support/developer/vix-api/vix17_reference/lang/com/functions/RunProgramInGuest.html

Categories