Today, what I want to offer is how I overcame various hurdles related to testing EXTjs with Selenium.
This probably doesn’t happen all that often, but this last week I came across the need to know which browser I was running my selenium test against. I figured that buried deep in the object structure of Selenium, there MUST be a way of finding out what browser I was currently running. As it turns out, I was right.
My experience with setting up Selenium Grid was frustrated by the lack of information available about exactly what I needed to do to get this working.
I’ve actually had this working for a while now and I’ve set it up, or helped others set it up now, several times. So, I guess it is time to write a post about it so I can just send people here when I need to explain the setup.
Note, the following discussion already assumes you know something about how to use Selenium without the Grid so there won’t be a lot of code here other than what is need to get the Grid up and running so you can run your test on it.
As many of you know, I’ve been using Selenium to do my website testing. And, if you’ve done any testing with Selenium yourself, you know that Selenium can be even slower if you are using Selenium Grid.
Running Selenium in parallel from .NET seems to be a problem because, as of the time of this writing, I’ve yet to find a viable way of running selenium test on multiple browsers using Selenium Grid. This doesn’t mean that there aren’t a few articles out there that have some kind of solution. But they’ve never satisfied me as something that I could easily plug into my already created test.
While my preferred testing tools are NUnit and SpecFlow, the method I am about to propose should work with any existing test harness you might want to use. The only prerequisite is that you are using Page Models to wrap your access to any particular web page.