Open essenius opened 5 years ago
The changes in 2.7.1 were to fix a problem with Slim using stdin and stdout when the messages contained non-English UTF-8 characters. (http://www.fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SliM.SlimProtocol.PortManagement). The default in Slim now is to use stdin and stdout. If you !define SLIM_PORT=0 or 1 or 8085, does the result change?
Using port 0, 8085 or 8475 (the last one is the one I normally use) doesn't make a difference. Using Port 1 doesn't work either, but gives a different error: Could not complete testing: fitnesse.testsystems.slim.SlimCommunicationException: Could not send/receive data with SUT. By the way, I get this same error with FitSharp 2.7.0 for port 1 (i.e. stdin/stdout); that's the reason I normally use a free port. Note this only happens with fixtures using Webdriver. I haven't seen it happen with any other fixtures, including those calling REST APIs or UI Automation functions.
I downloaded your repo and tried your GoogleTest with 2.7.1 and it worked. Is there any different test in your demos that fails with 2.7.1?
If I use 2.7.1, none of my tests using Selenium Webdriver work, With 2.7.0 they work if I use another port than 1.
I've created a C# fixture to drive web tests using Selenium Webdriver (see https://github.com/essenius/FitNesseFitSharpSelenium) using FitSharp (SLIM). This fixture works fine until FitSharp 2.7.0. However, when I use FitSharp 2.7.1, I get an exception with the fixture function that starts the browser and initiates the connection.
This is the stack trace I get when running any FitNesse test using that fixture:
The fixture raises a StopTestException because Selenium raises a WebDriverException, and that seems to indicate a timeout, as also the execution log hints at:
So the strange thing is that the driver service (ChromeDriver) has been started, while the exception says it could not be started. As said, this works fine in FitSharp 2.7.0: the browser gets started and the test runs correctly. Also, when I use RunnerW in 2.7.1 and attach the process in Visual Studio (without setting any breakpoints), I don't get the exception. If I run it in RunnerW without attaching the process, I do get the issue. This makes the suspicion of a timing related issue even stronger.
Is there anything in the 2.7.1 changes that could explain this?