| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
The webdrivers gem configures Selenium::WebDriver::Service.driver_path
as a proc which updates the web drivers and returns their path.
This commit introduces SystemTesting::Browser#preload, which runs this
proc early. This ensures that webdrivers update is run before forking
for parallel testing, but doesn't explicitly tie us to that gem (and I
think anything configured as driver_path probably makes sense to
eager-load).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a minor update to the named methods for the following:
- s/desired_capabilities/capabilities
- s/driver_options/capabilities
Since they are all the same thing we should keep the name the same
throughout the feature.
Updated docs to match / be a little bit clearer
Also updated the Gemfile for selenium-webdriver.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* There is currently no way to define specific browser capabilities since our SystemTest driver override the `option` key [Ref](https://github.com/rails/rails/blob/a07d0680787ced3c04b362fa7a238c918211ac70/actionpack/lib/action_dispatch/system_testing/driver.rb#L35)
This option key is used internally by selenium to add custom capabilities on the browser.
Depending on the Browser, some option are allowed to be passed inside a hash, the driver takes care of setting whatever you passed on the driver option. An example [here](https://github.com/rails/rails/blob/a07d0680787ced3c04b362fa7a238c918211ac70/actionpack/lib/action_dispatch/system_testing/driver.rb#L35) where you are allowed to pass args such as `--no-sandbox` etc
However this behavior was only meant for backward compatibility and as you can see it's deprecated.
The non-deprecated behavior is to create a `<Driver>::Option` object containing all the capabilities we want. This is what we [currently do](https://github.com/rails/rails/blob/a07d0680787ced3c04b362fa7a238c918211ac70/actionpack/lib/action_dispatch/system_testing/browser.rb#L34-L36) when chrome or firefox are in headless mode.
This PR allows to pass a block when calling `driven_by`, the block will be pased a `<Driver>::Option` instance. You can modify this object the way you want by adding any capabilities. The option object will be then passed to selenium.
```ruby
driven_by :selenium, using: :chrome do |driver_option|
driver_option.add_argument('--no-sandbox')
driver_option.add_emulation(device: 'iphone 4')
end
```
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Unlike `resize_window`, `resize_window_to` has three arguments.
https://github.com/thoughtbot/capybara-webkit/blob/d63c3c8e3ae844f0c59359532a6dcb50f4a64d0a/lib/capybara/webkit/driver.rb#L135-L143
Therefore, if pass only width and height just like `resize_window`,
`ArgumentError`will be raised.
To prevent this, explicitly pass window handler.
Follow up of #31046
|
| |
|
|
|
| |
>[DEPRECATION] Capybara::Webkit::Driver#resize_window is
deprecated. Please use Capybara::Window#resize_to instead.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible for developers toadd a custom driver and then call it
using `driven_by`. Because we were only skipping `register` for
`:rack_test` that meant any custom driver would attempt to be registered
as well.
The three listed here are special because Rails registers them with
special options. If you're registering your own custom driver then you
don't want to separately register that driver.
Fixes #29688
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
drivers.
When using `driver_by` with capybara-webkit or poltergeist,
SystemTesting::Driver will register the driver while passing
`screen_size` and `options` parameteres.
`options` could contain any option supported by the underlying driver.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Capybara drivers can handle some options such like `url`.
### before
```
# test/test_helper.rb
Capybara.register_driver :remote_chrome do |app|
Capybara::Selenium::Driver.new(app, browser: :chrome, url: "http://example.com/wd/hub")
end
# test/application_system_test_case.rb
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
driven_by :remote_chrome
end
```
### after
```
# test/application_system_test_case.rb
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
driven_by :selenium, using: :chrome, screen_size: [1400, 1400], options: {url: "http://chrome:4444/wd/hub"}
end
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Previously, `driven_by` would change the Capybara configuration when
the test case is loaded, and having multiple test classes with different
`driven_by` configs would fail as the last loaded would be effective.
|
|
|
* 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
|
