WebDriverException, thrown partly through the Selenium test, only at remote start

It seems that I have a problem with one of my test suites ONLY when starting remotely and ONLY when trying to interact with a specific element. I create and run this through VSTS.

Mistake:

OpenQA.Selenium.WebDriverException: A null response exception was thrown by sending an HTTP request to the remote WebDriver server for the URL (URL changed, is the localhost URL). The exception status was ReceiveFailure, and the message was as follows: The main connection was closed: An unexpected error occurred while receiving. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred while receiving. ---> System.IO.IOException: cannot read data from transport connection: existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: existing connection was forcibly closed by the remote host

HTML for the element I'm trying to type in a number (we use knockout):

<input type="number" min="0" max="999" data-bind="value: redacted).extend({ min: 0, required: { message: 'redacted' } }), disable: redacted" name="redacted" id="redacted" title="redacted" required="required" class=""> 

Do not mind redacted . I wanted to leave all the properties there to show which properties are set for the element, but the actual values ​​will be changed.

This is the code I use to enter the value into the element:

 IWebElement element = driver.FindElement(By.Id(elementID)); element.Clear(); element.SendKeys(value); 

This works with ChromeDriver. There are several other numeric fields in which I can successfully fill in the data without any problems.

Any ideas what might be wrong here and how to fix it?

+8
c # selenium selenium-chromedriver vsts
source share
1 answer

Something like a problem with SSL or the internal network on the VSTS build server, which is probably difficult to get more information because you should not have full access to this machine.

We also have Selenium tests on our continuous integration, but we use a local build server tied to VSTS, much more control over builds and processes.

+1
source share

All Articles