3 Replies Latest reply on Oct 3, 2011 3:15 AM by kpiwko

    Arquillian Drone initializes WebDriver instances with the default constructor

    vineet.reynolds

      The enrichment of test classes that use Drone to inject WebDriver instances, does not allow for Capabilities to be specified to the WebDriver when it is constructed. Also, the WebDriver instance is constructed before the @Before or @BeforeClass annotations are processed, and also before the testclass constructor is invoked. This means that properties/capabilties of the WebDriver that can be specified using Java System properties, are the only properties that can be set, and only by a static initializer that runs when the test class is loaded (and before the Drone extension enriches the test class), as shown below for the FirefoxDriver:

       

         static

         {

             System.setProperty("webdriver.firefox.profile", "Selenium-Custom");

             System.setProperty("webdriver.reap_profile ", "true");

         }

       

      It would have been better if the "webdriver.firefox.profile" and other properties for the FirefoxDriver be read from arquillian.xml and set by Drone during enrichment, instead of requiring a static initializer in the test class.

       

      Likewise, in the case of ChromeDriver, it would have been preferable for Drone to initialize the ChromeDriver with the one-arg constructor accepting Capabilties, so that Chrome browser can be started with specific command-line switches. Since there are no equivalent Java System properties for the ChromeDriver, that may be set using a static initializer, it is not possible to start the Chrome browser with desired command line switches.

        • 1. Re: Arquillian Drone initializes WebDriver instances with the default constructor
          kpiwko

          Hi Vineet,

           

          if you're using Arquillian Drone 1.0.0.CR2, you already have (some of) these properties available for FirefoxDriver. See https://docs.jboss.org/author/display/ARQ/Drone for available arquillian.xml properties.

           

          For your case, you can do the following:

           

          <extension name="webdriver">
              <property name="firefoxProfile">/foo/bar/.mozilla/profile</property>
              <property name="chromeSwitches">--load-extension=/path/to/extension/directory --start-maximized</property>
          </extension>
          

           

           

          In your test, you have to create a specific Driver in order to get its configuration specified in arquillian.xml.

          (note: it means that @Drone WebDriver driver will ignore these settings despite you've set implementationClass to FirefoxDriver or ChromeDriver)

           

          public testWithChrome(@Drone ChromeDriver driver) {
              // here you've included some of the capabilities for ChromeDriver
          }
          
          public testWithFirefox(@Drone FirefoxDriver driver) {
              // here you're using specified profile
          }
          

           

          I see that nowadays FirefoxDriver has now more properties than allowed by the Drone implementation.

          In Selenium Server extension we allow to specify <property name="systemProperties">, which can contain arbitrary properties.

          In your use case, it seems it makes sense to allow it for all WebDriver based drivers to solve your problems, what do you think?

           

          Implementing Capability based constructor for WebDriver would likely lead to Spring-like "beans" in arquillian.xml , which I'd like to avoid.

           

          Added note about specific *Driver.

          • 2. Re: Arquillian Drone initializes WebDriver instances with the default constructor
            vineet.reynolds

            Well, the updates in 1.0.0.CR2 do help. It is what I was looking for, but I think I didn't check the updated documentation (still on 1.0.0.CR1).

             

            Having looked at the WebDriver javadocs, I could find that only FirefoxDriver relies heavily on system properties, whereas the others require API calls involving Capabilities. So I think, having a "systemproperties" property in arquillian.xml for all WebDrivers is an overkill. But this could be considered, if the WebDriver project starts exposing other configuration parameters for  drivers via system properties.

             

            By the way (considering the properties in FirefoxDriver not yet available in Drone), I think there must be some way to map Drone releases to Selenium/WebDriver releases, for the purpose of knowning which releases of both projects are compatible with each other.

            • 3. Re: Arquillian Drone initializes WebDriver instances with the default constructor
              kpiwko

              Last 1.0.0.CR2 was tested against Selenium 2.5.0, so this version is verified as compatible. It is even present in Arquillian Drone Bom https://repository.jboss.org/nexus/service/local/artifact/maven/redirect?r=releases&g=org.jboss.arquillian.extension&a=arquillian-drone-bom&v=1.0.0.CR2&e=pom, so you get compatible release automagically.

               

              If all the WebDrivers (except Firefox) use Capabilities, we should reconsider its inclusion into arquillian.xml.