Exécuter des tests WebDriver NUnit sur plusieurs pilotes

Nous avons récemment commencé à utiliser WebDriver (en faveur de Selenium 1) pour effectuer des tests de navigateur, à l’aide du framework NUnit. Puisque nous voulons exécuter les tests dans divers navigateurs, nous définissons des pilotes pour chacun et les plaçons dans une liste lors de la configuration des appareils:

[TestFixtureSetUp] public void SetupTest() { // Load drivers Drivers = new List { new ChromeDriver(), ... }; 

Dans chaque test, nous parcourons la liste comme suit:

 [Test] public void SomeTest() { foreach (var driver in Drivers) { driver.Navigate().GoToUrl("..."); ... 

C’est mal de faire cela dans toutes les méthodes de test. Les méthodes de test ne doivent pas concerner le pilote sur lequel elles doivent travailler. Idéalement, nous aurions quelque chose comme ceci:

 public void SomeTest(IWebDriver driver) { driver.Navigate().GoToUrl("..."); ... 

Une façon de résoudre ce problème consiste à utiliser TestCases:

 [TestCase(new ChromeDriver())] [TestCase(new FireFoxDriver())] ... 

Mais cela fait beaucoup de duplication et déplace le problème de l’initialisation correcte des pilotes vers les atsortingbuts de chaque test. Pas vraiment un gain.

Existe-t-il un moyen de dire au framework NUnit d’exécuter toute la suite de tests et d’injecter un paramètre différent dans les tests individuels à chaque exécution? Ou y a-t-il une autre bonne solution à cela?

Vous devriez pouvoir utiliser TestCaseSourceAtsortingbute . Commencez par créer une classe couramment accessible fournissant la collection de pilotes Web:

 public static class WebDriverFactory { public static IWebDriver[] Drivers = { new ChromeDriver(), new FirefoxDriver(), ... }; } 

Ensuite, implémentez vos tests unitaires dépendants du pilote Web de la manière suivante:

 [Test, TestCaseSource(typeof(WebDriverFactory), "Drivers")] public void SomeTest(IWebDriver driver) { driver.Navigate().GoToUrl("..."); ... } 

Vous pouvez également définir une nouvelle classe d’ atsortingbuts qui hérite de TestCaseSourceAtsortingbute et qui implémente uniquement un constructeur par défaut, afin de réduire le nombre de saisies lors de la mise en œuvre de chaque test unitaire:

 public class WebDriverSourceAtsortingbute : TestCaseSourceAtsortingbute { public WebDriverSourceAtsortingbute() : base(typeof(WebDriverFactory), "Drivers") { } } 

En utilisant l’atsortingbut WedDriverSource hérité, les tests unitaires peuvent maintenant être simplifiés pour:

 [Test, WebDriverSource] public void SomeTest(IWebDriver driver) { driver.Navigate().GoToUrl("..."); ... } 

Il n’y a pas de “meilleure” façon de le faire, mais voici comment je l’ai accompli:

J’ai créé un Enum:

 ///  /// Enum that holds references to different browsers used in testing. ///  public enum BrowserTypeEnum { ///  /// Google Chrome. ///  Chrome, ///  /// Mozilla Firefox. ///  Firefox, ///  /// Internet Explorer. ///  InternetExplorer } 

Appelé cela dans TestFixture comme ceci:

 ///  /// Tests related to browsing Google ///  [TestFixture(BrowserTypeEnum.Chrome)] [TestFixture(BrowserTypeEnum.Firefox)] public class GoogleTests : AbstractTestFixture { } 

Dans AbstractTestFixture:

  ///  /// Create's the browser used for this test fixture. ///  /// Must always be called as part of the test fixture set up. ///  ///  /// It is the actual test fixture's responsibility to launch the browser. (Usually in the test fixture setup) ///  ///  protected override void CreateBrowser() { switch (BrowserType) { case BrowserTypeEnum.Chrome: Browser = new ChromeDriver(); break; case BrowserTypeEnum.Firefox: Browser = new FirefoxDriver(); break; case BrowserTypeEnum.InternetExplorer: Browser = new IEDriver(); break; default: break; } } 

Peut-être pas la meilleure solution, mais je l’ai trouvée assez lisible. L’alternative consiste à utiliser quelque chose comme Selenium Grid, ou peut-être à passer le type de pilote à NUnit et à le créer directement. Vous avez déjà essayé cela (en passant le type de pilote direct) et cela ne semble pas être ce que vous recherchez. La seule différence peut être que vous indiquez le type de pilote dans le dispositif de test, et non le test réel.

Si vous utilisez une solution CI Server, vous pouvez également créer un paramètre de configuration pour indiquer le navigateur à utiliser pour le test. Demandez au pilote CI de répéter les tests trois fois, en modifiant ce paramètre de configuration à chaque fois.

Je conviens que ce n’est pas la responsabilité des tests de savoir avec quel type de pilote ils travaillent, c’est pourquoi j’ai poussé cette responsabilité vers le haut dans le assembly de test. La façon dont je le fais n’est peut-être pas la plus “élégante”, mais c’est du moins la plus lisible pour moi. Quelqu’un regardant mon code peut facilement voir que cet appareil de test se répète, et quels navigateurs répètent les étapes.

Pour moi, la création du pilote doit toujours se faire dans TestFixture (et non dans une installation de test de base). La raison en est qu’il ya un peu de logique à faire avant d’ouvrir le navigateur: si cette logique échoue (dans une méthode Setup ou TestFixtureSetup), alors NUnit n’exécutera aucune méthode de déassembly. Donc, une fenêtre de navigateur sera laissée ouverte.

Donc, pour remédier à cela, la dernière chose que je fais dans TestFixtureSetup, avant l’exécution du test, s’appelle “CreateBrowser”.

Vous pouvez également écrire votre propre complément complémentaire TestCaseProvider pour NUnit pour effectuer cette itération sur tous les navigateurs.

Puis créez un nouvel atsortingbut comme celui-ci

 [Test, TestOnAllBrowsers] public void SomeTest(IWebDriver driver) { driver.Navigate().GoToUrl("..."); } 

pour marquer tous les tests devant s’exécuter sur tous les navigateurs et remplir la variable de driver dans le complément TestCaseProvider . Toutefois, cela peut devenir compliqué si vous utilisez déjà l’atsortingbut TestCase .