- 16 1月, 2018 1 次提交
-
-
由 Ashley Ellis Pierce 提交于
-
- 08 12月, 2017 1 次提交
-
-
由 bogdanvlviv 提交于
-
- 17 10月, 2017 1 次提交
-
-
由 yuuji.yaginuma 提交于
-
- 29 7月, 2017 1 次提交
-
-
由 Kir Shatrov 提交于
-
- 08 7月, 2017 1 次提交
-
-
由 eileencodes 提交于
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
-
- 02 7月, 2017 1 次提交
-
-
由 Matthew Draper 提交于
This reverts commit 3420a145, reversing changes made to afb66a5a.
-
- 01 7月, 2017 1 次提交
-
-
由 Kir Shatrov 提交于
-
- 03 6月, 2017 1 次提交
-
-
由 Mario Alberto Chávez 提交于
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.
-
- 13 3月, 2017 1 次提交
-
-
由 Fumiaki MATSUSHIMA 提交于
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 ```
-
- 09 3月, 2017 2 次提交
-
-
由 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.
-
由 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.
-
- 21 2月, 2017 2 次提交
-
-
由 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
-
由 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.
-