From 62c7d983848726bb9a512d687d2765c1dd78fe8d Mon Sep 17 00:00:00 2001 From: eileencodes Date: Tue, 27 Dec 2016 15:06:27 -0500 Subject: Add guides for system testing This adds the required guides for how to write and use system tests in your application. --- guides/source/testing.md | 254 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 251 insertions(+), 3 deletions(-) (limited to 'guides') diff --git a/guides/source/testing.md b/guides/source/testing.md index 6f783089a9..7b9fe5a74c 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -8,7 +8,7 @@ This guide covers built-in mechanisms in Rails for testing your application. After reading this guide, you will know: * Rails testing terminology. -* How to write unit, functional, and integration tests for your application. +* How to write unit, functional, integration, and system tests for your application. * Other popular testing approaches and plugins. -------------------------------------------------------------------------------- @@ -33,18 +33,25 @@ Rails creates a `test` directory for you as soon as you create a Rails project u ```bash $ ls -F test -controllers/ helpers/ mailers/ test_helper.rb -fixtures/ integration/ models/ +controllers/ helpers/ mailers/ system/ test_helper.rb +fixtures/ integration/ models/ system_test_helper.rb ``` The `helpers`, `mailers`, and `models` directories are meant to hold tests for view helpers, mailers, and models, respectively. The `controllers` directory is meant to hold tests for controllers, routes, and views. The `integration` directory is meant to hold tests for interactions between controllers. +The system test directory holds system tests, also known as acceptance tests. +System tests inherit from Capybara and perform in browser tests for your +application. + Fixtures are a way of organizing test data; they reside in the `fixtures` directory. A `jobs` directory will also be created when an associated test is first generated. The `test_helper.rb` file holds the default configuration for your tests. +The `system_test_helper.rb` holds the default configuration for your system +tests. + ### The Test Environment @@ -358,6 +365,7 @@ All the basic assertions such as `assert_equal` defined in `Minitest::Assertions * [`ActionView::TestCase`](http://api.rubyonrails.org/classes/ActionView/TestCase.html) * [`ActionDispatch::IntegrationTest`](http://api.rubyonrails.org/classes/ActionDispatch/IntegrationTest.html) * [`ActiveJob::TestCase`](http://api.rubyonrails.org/classes/ActiveJob/TestCase.html) +* [`ActionSystemTestCase`](http://api.rubyonrails.org/classes/ActionSystemTest.html) Each of these classes include `Minitest::Assertions`, allowing us to use all of the basic assertions in our tests. @@ -587,6 +595,246 @@ create test/fixtures/articles.yml Model tests don't have their own superclass like `ActionMailer::TestCase` instead they inherit from [`ActiveSupport::TestCase`](http://api.rubyonrails.org/classes/ActiveSupport/TestCase.html). +System Testing +-------------- + +System tests are full-browser acceptance tests that inherit from Capybara. +System tests allow for running tests in either a real browser or a headless +browser for testing full user interactions with your application. + +For creating Rails system tests, you use the `test/system` directory in your +application. Rails provides a generator to create a system test skeleton for us. + +```bash +$ bin/rails generate system_test users_create_test.rb + invoke test_unit + create test/system/users_create_test.rb +``` + +Here's what a freshly-generated system test looks like: + +```ruby +require 'test_helper' + +class UsersCreateTest < ActionSystemTestCase + # test "the truth" do + # assert true + # end +end +``` + +Here the test is inheriting from `ActionSystemTestCase`. This allows for no-setup +Capybara integration with Selenium Webdriver. + +### Changing the default settings + +Capybara requires that a driver be selected. Rails defaults to the Selenium +Driver and provides default settings to Capyara and Selenium so that system +tests work out of the box with no required configuration on your part. + +Some may prefer to use a headless driver so Rails provides a shim to set other +drivers for Capybara with minimal configuration. + +In the `system_test_helper.rb` that is generated with the application or test +you can set the driver: + +```ruby +require 'test_helper' + +class ActionSystemTestCase < ActionSystemTest::Base + ActionSystemTest.driver = :poltergeist +end +``` + +The drivers that Rails and Capybara support are `:rack_test`, `:poltergeist`, +`:capybara_webkit`, and of course `:selenium`. + +For selenium you can choose either the Rails configured driver `:rails_selenium` +or `:selenium`. The `:selenium` driver inherits from `CabybaraDriver` and is +the vanilla setup of selenium with Capybara if you don't want to use the +Rails defaults. + +The default settings for `:rails_selenium` driver uses the Chrome browser, +sets the server to Puma on port 28100 and the screen size to 1400 x 1400. + +You can change the default settings by initializing a new driver object. + +```ruby +require 'test_helper' + +class ActionSystemTestCase < ActionSystemTest::Base + ActionSystemTest.driver = ActionSystemTest::DriverAdapters::RailsSeleniumDriver.new( + browser: :firefox, + server: :webkit + ) +end +``` + +The shim for other Capybara drivers provide some defaults such as driver name +server, and port. To change any of those settings, you can initialize a new +`CapybaraDriver` object. + +```ruby +require 'test_helper' + +class ActionSystemTestCase < ActionSystemTest::Base + ActionSystemTest.driver = ActionSystemTest::DriverAdapters::CapybaraDriver.new( + driver: :poltergeist, + server: :webrick + ) +end +``` + +If your Capybara configuration requires more setup than provided by Rails, all +of that configuration can be put into the `system_test_helper.rb` file provided +by Rails. + +Please see Capybara's documentation for additional settings. + +### Helpers Available for System Tests + +`ActionSystemTest` provides a few helpers in addition to those provided previously +by Rails or by Capybara. + +The `ScreenshotHelper` is a helper designed to capture screenshots of your test. +This can be helpful for viewing the browser at the point a test failed, or +to view screenshots later for debugging. + +Two methods are provided: `take_screenshot` and `take_failed_screenshot`. +`take_failed_screenshot` is automatically included in the `system_test_helper.rb` +file and will take a screenshot only if the test fails. + +The `take_screenshot` helper method can be included anywhere in your tests to +take a screenshot of the browser. + +A method is provided by the drivers to determine whether the driver is capable +of taking screenshots. The `RackTest` driver for example does not support +screenshots. `supports_screenshots?` checks whether the driver supports +screenshots: + +```ruby +ActionSystemTest.driver.supports_screenshots? +=> true +``` + +The `ActiveJobSetup` helper configures your system tests for handling Active Job. + +Two helper methods are included in the setup and teardown blocks in the +`system_test_helper.rb` file. `set_queue_adapter_to_async` sets your Active Job +queue adapter to the async adapter and remembers the original adapter. + +In teardown the `reset_queue_adapter_to_original` method resets the Active Job +queue adapter back to the adapter your application has set for other environments. + +This is helpful for ensuring that jobs run async so that the test's that rely +on job code are correctly tested at the time they run. + +If you don't want these helper methods you can remove them from the setup and +teardown code in your `system_test_helper.rb`. + +The `AssertionsHelper` provides two helper methods for assertions. In Capybara +you can assert that a selector does or does not exist, but often you have cases +where you need to assert the same selector exsits multiple times with different +values. For example, if you have 6 avatars on the page and you want to assert +that each of them has the respective title for each person you can use +`assert_all_of_selectors` and pass the selector, items you are asserting exist, +and options. + +```ruby +assert_all_of_selectors(:avatar, 'Eileen', 'Jeremy') +assert_all_of_selectors(:avatar, 'Eileen', 'Jeremy', visible: all) +``` + +You can also assert that none of the selectors match with +`assert_none_of_selectors`: + +```ruby +assert_none_of_selectors(:avatar, 'Tom', 'Dan') +assert_none_of_selectors(:avatar, 'Tom', 'Dan') +``` + +### Implementing a system test + +Now we're going to add a system test to our blog application. We'll demonstrate +writing a system test by visiting the index page and creating a new blog article. + +If you used the scaffold generator, a system test skeleton is automatically +created for you. If you did not use the generator start by creating a system +test skeleton. + +```bash +$ bin/rails generate system_test articles +``` + +It should have created a test file placeholder for us. With the output of the +previous command we should see: + +```bash + invoke test_unit + create test/system/articles_test.rb +``` + +Now let's open that file and write our first assertion: + +```ruby +require 'system_test_helper' + +class UsersTest < ActionSystemTestCase + test "viewing the index" do + visit articles_path + assert_text "h1", "Articles" + end +end +``` + +The test should see that there is an h1 on the articles index and pass. + +Run the system tests. + +```bash +bin/rails test:system +``` + +#### Creating articles system test + +Now let's test the flow for creating a new article in our blog. + +```ruby +test "creating an article" do + visit articles_path + + click_on "New Article" + + fill_in "Title", with: "Creating an Article" + fill_in "Body", with: "Created this article successfully!" + + click_on "Create Article" + + assert_text "Creating an Article" +end +``` + +The first step is to call `visit articles_path`. This will take the test to the +articles index page. + +Then the `click_on "New Article"` will find the "New Article" button on the +index page. This will redirect the browser to `/articles/new`. + +Then the test will fill in the title and body of the article with the specified +text. Once the fields are filled in "Create Article" is clicked on which will +send a POST request to create the new article in the database. + +We will be redirected back to the the articles index page and there we assert +that the text from the article title is on the articles index page. + +#### Taking it further + +The beauty of system testing is that it is similar to integration testing in +that it tests the user's interaction with your controller, model, and view, but +system testing is much more robust and actually tests your application as if +a real user were using it. Going forward you can test anything that the user +themselves would do in your application such as commenting, deleting articles, +publishing draft articles, etc. Integration Testing ------------------- -- cgit v1.2.3 From 893c3b6282bc87c1f07a1f4084de8ff6709917b1 Mon Sep 17 00:00:00 2001 From: eileencodes Date: Fri, 10 Feb 2017 09:13:48 -0500 Subject: Update documentation and guides Update the documentation after rewriting a majority of the functionality for system testing. --- guides/source/testing.md | 134 +++++++++++++---------------------------------- 1 file changed, 36 insertions(+), 98 deletions(-) (limited to 'guides') diff --git a/guides/source/testing.md b/guides/source/testing.md index 7b9fe5a74c..5b8e14f296 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -39,7 +39,9 @@ fixtures/ integration/ models/ system_test The `helpers`, `mailers`, and `models` directories are meant to hold tests for view helpers, mailers, and models, respectively. The `controllers` directory is meant to hold tests for controllers, routes, and views. The `integration` directory is meant to hold tests for interactions between controllers. -The system test directory holds system tests, also known as acceptance tests. +The system test directory holds system tests, which are used for full browser +testing of your application. System tests allow you to test your application +the way your users experience it and help you test your JavaScript as well. System tests inherit from Capybara and perform in browser tests for your application. @@ -598,9 +600,11 @@ Model tests don't have their own superclass like `ActionMailer::TestCase` instea System Testing -------------- -System tests are full-browser acceptance tests that inherit from Capybara. +System tests are full-browser tests that can be used to test your application's +JavaScript and user experience. System tests use Capybara as a base. + System tests allow for running tests in either a real browser or a headless -browser for testing full user interactions with your application. +driver for testing full user interactions with your application. For creating Rails system tests, you use the `test/system` directory in your application. Rails provides a generator to create a system test skeleton for us. @@ -614,7 +618,7 @@ $ bin/rails generate system_test users_create_test.rb Here's what a freshly-generated system test looks like: ```ruby -require 'test_helper' +require "system_test_helper" class UsersCreateTest < ActionSystemTestCase # test "the truth" do @@ -623,78 +627,58 @@ class UsersCreateTest < ActionSystemTestCase end ``` -Here the test is inheriting from `ActionSystemTestCase`. This allows for no-setup -Capybara integration with Selenium Webdriver. +By default, system tests are run with the Selenium driver, using the Chrome +browser, on port 21800 with Puma, and a screen size of 1400x1400. The next +section explains how to change the default settings. ### Changing the default settings -Capybara requires that a driver be selected. Rails defaults to the Selenium -Driver and provides default settings to Capyara and Selenium so that system -tests work out of the box with no required configuration on your part. +Rails makes changing the default settings for system test very simple. All +the setup is abstracted away so you can focus on writing your tests. -Some may prefer to use a headless driver so Rails provides a shim to set other -drivers for Capybara with minimal configuration. +When you generate a new application or scaffold, a `system_test_helper.rb` file +is created in the test directory. This is where all the configuration for your +system tests should live. -In the `system_test_helper.rb` that is generated with the application or test -you can set the driver: +If you want to change the default settings you can simple change what the system +tests are "driven by". Say you want to change the driver from Selenium to +Poltergeist. First add the Poltergeist gem to your Gemfile. Then in your +`system_test_helper.rb` file do the following: ```ruby -require 'test_helper' +require "test_helper" +require "capybara/poltergeist" class ActionSystemTestCase < ActionSystemTest::Base - ActionSystemTest.driver = :poltergeist + driven_by :poltergeist end ``` -The drivers that Rails and Capybara support are `:rack_test`, `:poltergeist`, -`:capybara_webkit`, and of course `:selenium`. - -For selenium you can choose either the Rails configured driver `:rails_selenium` -or `:selenium`. The `:selenium` driver inherits from `CabybaraDriver` and is -the vanilla setup of selenium with Capybara if you don't want to use the -Rails defaults. - -The default settings for `:rails_selenium` driver uses the Chrome browser, -sets the server to Puma on port 28100 and the screen size to 1400 x 1400. - -You can change the default settings by initializing a new driver object. +If you want to keep the Selenium driver but change the browser or port you +can pass Firefox and the port to driven by. The driver is a required +argument, all other arguments are optional. ```ruby -require 'test_helper' +require "test_helper" class ActionSystemTestCase < ActionSystemTest::Base - ActionSystemTest.driver = ActionSystemTest::DriverAdapters::RailsSeleniumDriver.new( - browser: :firefox, - server: :webkit - ) + driven_by :selenium, using: :firefox, on: 3000 end ``` -The shim for other Capybara drivers provide some defaults such as driver name -server, and port. To change any of those settings, you can initialize a new -`CapybaraDriver` object. - -```ruby -require 'test_helper' - -class ActionSystemTestCase < ActionSystemTest::Base - ActionSystemTest.driver = ActionSystemTest::DriverAdapters::CapybaraDriver.new( - driver: :poltergeist, - server: :webrick - ) -end -``` +The driver name is a required argument for `driven_by`. The optional arguments +that can be passed to `driven_by` are `:using` for the browser (this will only +be used for non-headless drivers like Selenium), `:on` for the port Puma should +use, and `:screen_size` to change the size of the screen for screenshots. If your Capybara configuration requires more setup than provided by Rails, all of that configuration can be put into the `system_test_helper.rb` file provided by Rails. -Please see Capybara's documentation for additional settings. +Please see [Capybara's documentation](https://github.com/teamcapybara/capybara#setup) +for additional settings. -### Helpers Available for System Tests - -`ActionSystemTest` provides a few helpers in addition to those provided previously -by Rails or by Capybara. +### Screenshot Helper The `ScreenshotHelper` is a helper designed to capture screenshots of your test. This can be helpful for viewing the browser at the point a test failed, or @@ -707,52 +691,6 @@ file and will take a screenshot only if the test fails. The `take_screenshot` helper method can be included anywhere in your tests to take a screenshot of the browser. -A method is provided by the drivers to determine whether the driver is capable -of taking screenshots. The `RackTest` driver for example does not support -screenshots. `supports_screenshots?` checks whether the driver supports -screenshots: - -```ruby -ActionSystemTest.driver.supports_screenshots? -=> true -``` - -The `ActiveJobSetup` helper configures your system tests for handling Active Job. - -Two helper methods are included in the setup and teardown blocks in the -`system_test_helper.rb` file. `set_queue_adapter_to_async` sets your Active Job -queue adapter to the async adapter and remembers the original adapter. - -In teardown the `reset_queue_adapter_to_original` method resets the Active Job -queue adapter back to the adapter your application has set for other environments. - -This is helpful for ensuring that jobs run async so that the test's that rely -on job code are correctly tested at the time they run. - -If you don't want these helper methods you can remove them from the setup and -teardown code in your `system_test_helper.rb`. - -The `AssertionsHelper` provides two helper methods for assertions. In Capybara -you can assert that a selector does or does not exist, but often you have cases -where you need to assert the same selector exsits multiple times with different -values. For example, if you have 6 avatars on the page and you want to assert -that each of them has the respective title for each person you can use -`assert_all_of_selectors` and pass the selector, items you are asserting exist, -and options. - -```ruby -assert_all_of_selectors(:avatar, 'Eileen', 'Jeremy') -assert_all_of_selectors(:avatar, 'Eileen', 'Jeremy', visible: all) -``` - -You can also assert that none of the selectors match with -`assert_none_of_selectors`: - -```ruby -assert_none_of_selectors(:avatar, 'Tom', 'Dan') -assert_none_of_selectors(:avatar, 'Tom', 'Dan') -``` - ### Implementing a system test Now we're going to add a system test to our blog application. We'll demonstrate @@ -777,7 +715,7 @@ previous command we should see: Now let's open that file and write our first assertion: ```ruby -require 'system_test_helper' +require "system_test_helper" class UsersTest < ActionSystemTestCase test "viewing the index" do -- cgit v1.2.3 From 1a0ca84a064b07ecab798793a3d7ebe89bb6367c Mon Sep 17 00:00:00 2001 From: eileencodes Date: Sun, 19 Feb 2017 11:50:42 -0500 Subject: Move and rename system tests * 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 --- guides/source/testing.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'guides') diff --git a/guides/source/testing.md b/guides/source/testing.md index 5b8e14f296..366ab0b2a1 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -367,7 +367,7 @@ All the basic assertions such as `assert_equal` defined in `Minitest::Assertions * [`ActionView::TestCase`](http://api.rubyonrails.org/classes/ActionView/TestCase.html) * [`ActionDispatch::IntegrationTest`](http://api.rubyonrails.org/classes/ActionDispatch/IntegrationTest.html) * [`ActiveJob::TestCase`](http://api.rubyonrails.org/classes/ActiveJob/TestCase.html) -* [`ActionSystemTestCase`](http://api.rubyonrails.org/classes/ActionSystemTest.html) +* [`ActionDispatch::SystemTestCase`](http://api.rubyonrails.org/classes/ActionDispatch/SystemTestCase.html) Each of these classes include `Minitest::Assertions`, allowing us to use all of the basic assertions in our tests. @@ -620,7 +620,7 @@ Here's what a freshly-generated system test looks like: ```ruby require "system_test_helper" -class UsersCreateTest < ActionSystemTestCase +class UsersCreateTest < ApplicationSystemTestCase # test "the truth" do # assert true # end @@ -649,7 +649,7 @@ Poltergeist. First add the Poltergeist gem to your Gemfile. Then in your require "test_helper" require "capybara/poltergeist" -class ActionSystemTestCase < ActionSystemTest::Base +class ApplicationSystemTestCase < ActionDispatch::SystemTestCase driven_by :poltergeist end ``` @@ -661,7 +661,7 @@ argument, all other arguments are optional. ```ruby require "test_helper" -class ActionSystemTestCase < ActionSystemTest::Base +class ApplicationSystemTestCase < ActionDispatch::SystemTestCase driven_by :selenium, using: :firefox, on: 3000 end ``` @@ -717,7 +717,7 @@ Now let's open that file and write our first assertion: ```ruby require "system_test_helper" -class UsersTest < ActionSystemTestCase +class UsersTest < ApplicationSystemTestCase test "viewing the index" do visit articles_path assert_text "h1", "Articles" -- cgit v1.2.3 From 2d61c5d846f8dd3a02080fedce7ab63b8d314db6 Mon Sep 17 00:00:00 2001 From: eileencodes Date: Mon, 20 Feb 2017 14:38:46 -0500 Subject: Rename system_test_helper -> application_system_test_case This renames the system test helper file to be application system test case to match what the rest of Rails does. In the future we should consider changing the test_helper to match. --- guides/source/testing.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'guides') diff --git a/guides/source/testing.md b/guides/source/testing.md index 366ab0b2a1..fe0dbf6c50 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -34,7 +34,7 @@ Rails creates a `test` directory for you as soon as you create a Rails project u ```bash $ ls -F test controllers/ helpers/ mailers/ system/ test_helper.rb -fixtures/ integration/ models/ system_test_helper.rb +fixtures/ integration/ models/ application_system_test_case.rb ``` The `helpers`, `mailers`, and `models` directories are meant to hold tests for view helpers, mailers, and models, respectively. The `controllers` directory is meant to hold tests for controllers, routes, and views. The `integration` directory is meant to hold tests for interactions between controllers. @@ -51,7 +51,7 @@ A `jobs` directory will also be created when an associated test is first generat The `test_helper.rb` file holds the default configuration for your tests. -The `system_test_helper.rb` holds the default configuration for your system +The `application_system_test_case.rb` holds the default configuration for your system tests. @@ -618,12 +618,12 @@ $ bin/rails generate system_test users_create_test.rb Here's what a freshly-generated system test looks like: ```ruby -require "system_test_helper" +require "application_system_test_case" class UsersCreateTest < ApplicationSystemTestCase - # test "the truth" do - # assert true - # end + visit users_url + + assert_selector "h1", text: "Users" end ``` @@ -636,14 +636,14 @@ section explains how to change the default settings. Rails makes changing the default settings for system test very simple. All the setup is abstracted away so you can focus on writing your tests. -When you generate a new application or scaffold, a `system_test_helper.rb` file +When you generate a new application or scaffold, a `application_system_test_case.rb` file is created in the test directory. This is where all the configuration for your system tests should live. If you want to change the default settings you can simple change what the system tests are "driven by". Say you want to change the driver from Selenium to Poltergeist. First add the Poltergeist gem to your Gemfile. Then in your -`system_test_helper.rb` file do the following: +`application_system_test_case.rb` file do the following: ```ruby require "test_helper" @@ -672,7 +672,7 @@ be used for non-headless drivers like Selenium), `:on` for the port Puma should use, and `:screen_size` to change the size of the screen for screenshots. If your Capybara configuration requires more setup than provided by Rails, all -of that configuration can be put into the `system_test_helper.rb` file provided +of that configuration can be put into the `application_system_test_case.rb` file provided by Rails. Please see [Capybara's documentation](https://github.com/teamcapybara/capybara#setup) @@ -685,7 +685,7 @@ This can be helpful for viewing the browser at the point a test failed, or to view screenshots later for debugging. Two methods are provided: `take_screenshot` and `take_failed_screenshot`. -`take_failed_screenshot` is automatically included in the `system_test_helper.rb` +`take_failed_screenshot` is automatically included in the `application_system_test_case.rb` file and will take a screenshot only if the test fails. The `take_screenshot` helper method can be included anywhere in your tests to @@ -715,12 +715,12 @@ previous command we should see: Now let's open that file and write our first assertion: ```ruby -require "system_test_helper" +require "application_system_test_case" class UsersTest < ApplicationSystemTestCase test "viewing the index" do visit articles_path - assert_text "h1", "Articles" + assert_selector "h1", text: "Articles" end end ``` -- cgit v1.2.3 From 42a6dbdf8480b96c4a0ac6e1dab215ae9dd77d1d Mon Sep 17 00:00:00 2001 From: eileencodes Date: Mon, 20 Feb 2017 16:08:20 -0500 Subject: Clean up documentation There were some grammar issues and incorrect information in the system tests documentation. --- guides/source/testing.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'guides') diff --git a/guides/source/testing.md b/guides/source/testing.md index fe0dbf6c50..c7897a42a1 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -628,8 +628,8 @@ end ``` By default, system tests are run with the Selenium driver, using the Chrome -browser, on port 21800 with Puma, and a screen size of 1400x1400. The next -section explains how to change the default settings. +browser, and a screen size of 1400x1400. The next section explains how to +change the default settings. ### Changing the default settings @@ -654,7 +654,7 @@ class ApplicationSystemTestCase < ActionDispatch::SystemTestCase end ``` -If you want to keep the Selenium driver but change the browser or port you +If you want to keep the Selenium driver but change the browser you can pass Firefox and the port to driven by. The driver is a required argument, all other arguments are optional. @@ -662,7 +662,7 @@ argument, all other arguments are optional. require "test_helper" class ApplicationSystemTestCase < ActionDispatch::SystemTestCase - driven_by :selenium, using: :firefox, on: 3000 + driven_by :selenium, using: :firefox end ``` @@ -680,13 +680,13 @@ for additional settings. ### Screenshot Helper -The `ScreenshotHelper` is a helper designed to capture screenshots of your test. +The `ScreenshotHelper` is a helper designed to capture screenshots of your tests. This can be helpful for viewing the browser at the point a test failed, or to view screenshots later for debugging. Two methods are provided: `take_screenshot` and `take_failed_screenshot`. -`take_failed_screenshot` is automatically included in the `application_system_test_case.rb` -file and will take a screenshot only if the test fails. +`take_failed_screenshot` is automatically included in `after_teardown` inside +Rails. The `take_screenshot` helper method can be included anywhere in your tests to take a screenshot of the browser. -- cgit v1.2.3