Running Selenium Nunit tests on Teamcity vs. locally

Question

I'm running Selenium Nunit tests on the TeamCity server which is running locally on my server. The problem I'm having is some of the tests pass and some of them fail. However, when I run the same tests by opening up visual studios manually and running the tests from there they seem to pass.

I've tried restarting the TeamCity server, tried cleaning all the files. Deleting the files and rebuilding everything but nothing seems to be working. There is nothing wrong with the tests and getting them to run, it's only the tests fail the assertions while the same tests pass the assertions when I run them manually through visual studios.

Any thoughts on what could be causing this?

Answer 1

One possibility is that your TeamCity is using a different version of NUnit from your local system. Another is that TC generates an NUnit project file by default and runs tests using that rather than executing the assemblies directly.

Answer 2

I'm facing the same issue with Teamcity server,my configuration is Visual Studio with Nunit and Selenium Webdriver.

What you can do,that helped my is to set a Wait method for those elements that are dynamically loading on the page.When a TeamCity agent is running a build on VM,the tests are running in headless mode,and the TeamCity configuration does not have a Wait/Thread.Sleep by default implemented. @chillax786

Answer 3

If a specific test is always false with a not clickable element, that's because you use a different resolution of your webdriver on your TC server than on locally.

If this test throws this error sometimes, it's because your website responds more quickly on your TC server than locally and so sometimes you can't click your element sometimes you can.

You must be sure (somewhere in your code) that you can click on your elements when you used them.

I encountered these kinds of problem with SPA sites.

I wrote a invisible span where I flag that my page is really ready to be used.

With that invisible span added I never saw that problem again.