This discussion will revolve around the two main testing packages in use today – NUnit and Selenium. Both are fantastic tools but expect you to write tests in a single scenario, perhaps a ChromeDriver as an example. Multiple browser testing usually requires repeating the test for each browser you specify, here we solve this issue by describing in one place which browsers we would like to test and then for each scenario it will automatically be tested in each browser specified.
For this demo I’ll be using a dummy MVC application which when the homepage is called returns “Hello World!”
And the result:
Really we should have made the test before the content but let’s let that one slide for now. We should have a test which confirms that when we reach the homepage of our application that “Hello World!” is returned!
The Automation Test
Here you can see we have something similar to a standard unit test format. We are opting for one class per page; this is not always suitable for automation tests so consider your application beforehand.
We like to follow two other conventions when writing any tests. The method name should follow:
This has the advantages of A) Being consistent and flexible and B) Making it very easy to determine through the method name what use case is failing. The second convention is to structure all code into Arrange, Act and Assert blocks – here the verbosity is a just for demo purposes but by following this structure it allows any developer to clearly see which code is actually being tested.
The last thing to do is check out test passes.
Enhancing the Automation Test
Now the easy part is out of the way we can focus on bootstrapping multi browser functionality, we’ll do this by using the magic of Inheritance and method attributes.
Here we’ve made a MultiBrowserFixtureBase class which has three TestFixtures, the switch here is simply because TestFixture don’t currently let you pass in objects and the cleanest solution is to switch on a string instead. This class on its own will generate three tests for each parameter and by inheriting this class we will also inherit the TestFixture attributes.
In our HomeIndexTests we have inherited MultiBrowserFixtureBase and NUnit has recognised that we now have three tests for each individual test which pass in different browser parameters. The last thing to do is change our hardcoded chrome driver in the SetUp to a more generic version. Let’s do that by using a custom driver which employs the decorator pattern.
Here we add a contract to the class for IWebDriver and also take in an IWebDriver, delegating nearly all of the responsibility to the passed in class, however we have added some extra functionality so that we only specify our base URL in one place then append the relativeUrl and we wait for the elements to load before trying to query the page.
The final step is to replace our ChromeDriver in our main testing class.
Now we have a flow whereby for each TextFixture on the base class it will populate the Driver property, and for each test class it will pass in that public property to our decorator class which will delegate the responsibility.
Our code is now complete and if you run your test suite you should see that for every test you write it will run the test in each browser we have specified on the base class.
Enhancing the Enhanced Automation Test
This feature is very powerful and can also be used for other abstractions like multi regional support.
Here we have simply added another parameter countryCode and added the additional test fixtures for GB, EU and US. Now for each test we write we will have 9 tests in total, this is somewhat extreme but is a great idea in places which are mission critical such as a checkout page and it demonstrates the power of good abstractions.