Using Selenium to test across multiple browsers

When having a set of Selenium Tests one nice thing to be able to do would be to run these same tests against multiple browsers. The nicest solution to do this that I’ve discovered is to use the [TestFixture] attribute (Note: Only available in NUnit and not in MSTest).

This is a 2-step process:
1. Introduce a base factory class to initialise the web driver with the specific browser
2. Update the test classes to derive from the base class and add the TestFixture attributes.

Step 1:

So, for example, to test against Chrome and Internet Explorer 11, introduce the Factory Base Class:

    public class WebDriverFactory
    {
        public IWebDriver _driver;

        protected WebDriverFactory(BrowserType type)
        {
            _driver = WebDriver(type);
        }

        public enum BrowserType
        {
            IE11,
            Chrome
        }

        [TearDown]
        public void Close()
        {
            _driver.Close();
        }

        public static IWebDriver WebDriver(BrowserType type)
        {
            IWebDriver driver = null;

            switch (type)
            {
                case BrowserType.Chrome:
                    driver = ChromeDriver();
                    break;

                case BrowserType.IE11:
                    driver = IeDriver();
                    break;
            }

            return driver;
        }

        private static IWebDriver IeDriver()
        {
            InternetExplorerOptions options = new InternetExplorerOptions();
            options.EnsureCleanSession = true;
            options.IgnoreZoomLevel = true;
            IWebDriver driver = new InternetExplorerDriver(options);
            return driver;
        }

        private static IWebDriver ChromeDriver()
        {
            ChromeOptions options = new ChromeOptions();
            IWebDriver driver = new ChromeDriver(options);
            return driver;
        }
    }

Step 2 – Update Test Cases

With this in place, alter the test classes to:


    [TestFixture(BrowserType.Chrome)]
    [TestFixture(BrowserType.IE11)]
    public class NUnitTests : WebDriverFactory
    {
        public NUnitTests(BrowserType browser) : base(browser)
        {

        }

        [Test]
        public void Test1()
        {
            _driver.Navigate().GoToUrl("https://www.google.co.uk/");
            Assert.AreEqual("https://www.google.co.uk/", _driver.Url);
        }
    }

References

Stack Overflow: Testing framework on multiple browsers using selenium and NUnit

Advertisements

ApiController Validation in .Net Core 2.1/2.2 – Unit Testing

One of the additions in .NET Core 2.1 was the introduction of the [ApiController] attribute which could be applied at Controller level to validate the Model State, removing a lot of boilerplate code around the system. (NB. .NET Core 2.2 introduced the ability to set this at assembly level, e.g.


[assembly: ApiController]
namespace WebApp

This can be applied on any class, but I’ve choosen Startup.cs as a fairly obvious place for the configuration of most things.

Before .NET Core 2.1, a lot of code would have looked like the following:


public async Task<IActionResult> ActionToPerform(InputModel inputModel)
{
   if (!ModelState.IsValid)
   {
      return BadRequest();
   }
}

This boilerplate code is likely to be scattered the code base.

With this code in place, the invalid state of the model can tested using Unit Tests as follows (NB. The error must be manually set, as the model binding won’t happen without the middleware pipeline)


var controller = new StudentController();

// force model state to be invalid.
controller.ModelState.AddModelError(string.Empty, "Test Error");

Assert.IsFalse(controller.ModelState.IsValid, "Model state has remained valid.");

// Test for BadRequest being returned
Var result = await controller.ActionToPerform(model);
BadRequestResult badRequestResult = result as BadRequestResult;

Assert.IsNotNull(badRequestResult, "Wrong type returned.");

With this test in place, and hopefully passing, now comes the opportunity to introduce the ApiController attribute. In theory that means that the boilerplate code can be removed, and the pass will continue to pass.

Unfortunately that’s not the case. As per the binding on the model state, I’m assuming this happens elsewhere in the pipeline. Indeed it can be proved to be working outside of the Unit Tests by using Postman to trigger a request and see a BadRequest (400) be returned – provided an invalid object is supplied).

As such the Unit Test needs to change to check for the presence of ApiController – either on the Controller itself, or at Assembly level, depending on where its been declared. Here is the test for assembly level, on the StartUp class:

var customAttributes = typeof(Startup).Assembly.GetCustomAttributes(true);

var entry = customAttributes.FirstOrDefault(a => a.GetType().Name == "ApiControllerAttribute");

Assert.IsNotNull(entry);

References:

https://alenjalex.github.io/dev/dev/Asp.Net-Core-ModelState-Validation-Using-UnitTest/

https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/testing?view=aspnetcore-2.2

https://docs.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-2.1?view=aspnetcore-2.2

https://docs.microsoft.com/en-us/aspnet/core/web-api/index?view=aspnetcore-2.2