I'm working on a suite of Selenium WebDriver (not Selenium RC and not using Selenium-Server) tests that are being executed by a command-line call to MSTest. I've broken them into test classes for each browser we plan on testing (Chrome, Firefox and IE9, for now) and each test class has a startup method that logs in to the system under test and then executes the test(s) requested and a TearDown method that closes the browser using WebDriver.Quit().
On my development machine everything is hunky-dory, but on our build machine the class initialization/start-up method executes fine and logs into the site, but as soon as the first actual test starts the test runner closes with the error message:
OpenQA.Selenium.WebDriverException: Unexpected error. System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:59982
obviously the port changes depending on which browser's being tested; when I run the whole suite I get errors on different ports for the tests for IE, Firefox, and Chrome - two errors for each browser (as the suite currently has two tests for each browser)
Windows Firewall is off for the build machine, and checking netstat before running the tests shows that the port's not in use; if I debug the tests and stop after the startup code runs but before the test runs, of course the port is in use. 127.0.0.1 and localhost are the same as well.
I get the same error whether or not I call the test via the command line, run/debug it from within Visual Studio using the VS Test tools, or by executing my console app, which calls MSTest via Process.Start(). The exception is thrown on the first FindElement() call.
Where can I start looking to figure out why this is failing on the build machine and not on my dev box?
The issue here was that in trying to implement some more robust error handling during startup I place a call to the Teardown code in the finally block of a try/catch wrapped around the login code, so as soon as the test harness was done logging in I was closing and cleanin up the WebDriver instance, so when the test ran there wasn't a WebDriver there to communicate with.
I suspect when I as looking at the "same" code on my dev machine the libraries that were actually running didn't have that block in them.
When you run an application from Visual Studio it fires up a server listening on a certain port. In your case 59982.
You need to actually have your web application running on its own on the test environments before running your test against it.
On your dev machine your application is running on that port. I'm guessing on your remote machines that is not the case.
来源：https://stackoverflow.com/questions/13276686/selenium-webdriver-tests-fail-with-system-net-webexception-unable-to-connect