1. 29 3月, 2017 1 次提交
    • F
      Make `driven_by` overridable · 24e0fa7c
      Fumiaki MATSUSHIMA 提交于
      Sometimes we want to use rack_test partially instead of selenium for test speed:
      
      ```ruby
      class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
        driven_by :selenium, using: :chrome, screen_size: [1400, 1400], options: {url: "http://chrome:4444/wd/hub"}
      end
      
      class WithJavaScriptTest < ApplicationSystemTestCase
      end
      
      class WithoutJavaScriptTest < ApplicationSystemTestCase
        driven_by :rack_test
      end
      ```
      
      In the abobe case, `WithoutJavaScriptTest` uses selenium because
      `SystemTestCase` calls superclass' driver on `#initialize` (`self.class.superclass.driver.use`).
      
      Using `class_attribute` can handle inherited `driven_by`.
      24e0fa7c
  2. 09 3月, 2017 2 次提交
    • E
      Call system test driver per-instance rather than globally · 7c9af60e
      eileencodes 提交于
      Previously the system test subclasses would call `driven_by` when the
      app booted and not again when the test was initialized which resulted in
      the driver from whichever class was called last to be used in tests.
      
      In rails/rails#28144 the `driven_by` method was changed to run `use` on
      setup and `reset` on teardown. While this was a viable fix this really
      pointed to the problem that system test `driven_by` was a global
      setting, rather than a per-class setting.
      
      To alieviate this problem calling the driver should be done on an
      instance level, rather than on the global level. I added an `initialize`
      method to `SystemTestCase` which will call `use` on the superclass
      driver. Running the server has been moved to `start_application` so that
      it only needs to be called once on boot and no options from `driven_by`
      were being passed to it.
      
      This required a largish rewrite of the tests. Each test needs to utilize
      the subclass so that it can properly test the drivers.
      `ActionDispatch::SystemTestCase` shouldn't be called directly anymore.
      7c9af60e
    • E
      Refactor system test driver/browser · 4dbebe48
      eileencodes 提交于
      Since using a browser is only for selenium it doesn't really make sense
      to have a separate class for handling it there. This brings a lot of the
      if/else out of the main SystemTestCase class and into the Driver class
      so we can abstract away all that extra work.
      4dbebe48
  3. 25 2月, 2017 1 次提交
  4. 21 2月, 2017 3 次提交
    • E
      Move and rename system tests · 1a0ca84a
      eileencodes 提交于
      * Move system tests back into Action Pack
      * Rename `ActionSystemTest` to `ActionDispatch::SystemTestCase`
      * Remove private base module and only make file for public
      `SystemTestCase` class, name private module `SystemTesting`
      * Rename `ActionSystemTestCase` to `ApplicationSystemTestCase`
      * Update corresponding documentation and guides
      * Delete old `ActionSystemTest` files
      1a0ca84a
    • E
      Rename server and remove optional port setting · 0a683085
      eileencodes 提交于
      I've renamed the server to `rails_puma` so that it doesn't override
      Capybara's default puma server. I've also removed the hard port setting.
      Users can simply use `Capybara.server_port` writer to set the port if
      they require that.
      0a683085
    • E
      Rewrite API for ActionSystemTest · 3dfbe7e4
      eileencodes 提交于
      This is a major rewrite of what existed previously. After discussing
      this feature with DHH I realized that I was looking at the setup all
      wrong.
      
      I had originally mentally broken it into "what Rails wants" and "what
      Capybara already has".
      
      What happened after looking at it from DHH's angle was that I saw there
      was no reason to group settings by Driver but instead the following
      groups:
      
      - There will always be a `Driver`
        - This can selenium, poltergeist, or capybara webkit. Capybara already
          provides all of these and there's no reason to break them into a
          category of Rails' usese Selenium like this and Capybara uses it
          like that.
      - Only Selenium drivers care about `Browser`
        - Because of this it was weird to set it only in the Rails end.
        - Therefore only `Browser`, and not `Driver` cares about
          `screen_size`.
      - Puma is the default `Server` in Rails
        - Therefore there's no reason to explictly support Webkit
      
      Once I looked at it from this angle I was able to abstract all the
      settings away from grouping the drivers with their options.
      
      Now all the driver, server, and browser settings are abstracted away and
      not part of the public facing API.
      
      This means there's no requirement to initialize new classes to change
      the default settings and the public options API is much smaller.
      
      All of Rails preferred defaults are still there (selenium with port
      21800 using the chrome browser with a screen size of 1400x1400) but
      changing these no longer requires initializing a new class or
      understanding which driver you're using underneath (rails defaults or
      capybaras defaults respectively). Rails opinions are now simple defaults
      instead of doing a them versus us setup with Drivers and explicit
      options.
      
      Changing the defaults is simple. Call `driven_by` with different
      settings to change the defaults which will on their own initialize new
      classes and change the default settings.
      
      Use poltergeist with port 3000 for Puma
      
      ```
      driven_by :poltergeist, on: 3000
      ```
      
      Use selenium with the Chrome browser and a screen size of 800x800
      ```
      driven_by :selenium, using: :firefox, screen_size: [ 800, 800 ]
      ```
      
      The entire setup of how browser and drivers interact with each other are
      abstracted away and the only required argument is the driver name.
      3dfbe7e4