| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally I had set up system testing to have one configuration option
to be set in the test environment. After thinking it over I think a
generated class on app creation would be best. The reason for this is
Capybara has a ton of configuration options that I'm sure some folks
want to use.
Thinking about how we handle screenshots, database transactions, and a
whole bunch of other settings it would be better for users to be able to
turn all of that on and off.
When an app or scaffold is generated a `test/system_test_helper.rb` test
helper will be generated as well. This will contain the class for tests
to inherit from `ActionSystemTestCase` which will inherit from
`ActionSystemTest::Base`. Here is where users can change the test
driver, remove the screenshot helper, and add their additional Capybara
configuration.
|
|
|
|
|
|
|
|
|
|
| |
Renames `Rails::SystemTestCase` to `ActionSystemTest` and moves it to a
gem under the Rails name.
We need to name the class `ActionSystemTestCase` because the gem expects
a module but tests themselves expect a class.
Adds MIT-LICENSE, CHANGELOG, and README for the future.
|
|
* Generates system test requirements with new Rails app
* Includes required default gems in Gemfile for Rails app
* Generates a single system test case
* Generates a system test case with scaffold
|