- 21 2月, 2017 40 次提交
-
-
由 Prem Sichanugrist 提交于
This issue is only appear when you try to call `define_attribute_method` and passing a symbol in Active Record. It does not appear in isolation in Active Model itself. Before this patch, when you run `User.define_attribute_method :foo`, you will get: NoMethodError: undefined method `unpack' for :foo:Symbol from activerecord/lib/active_record/attribute_methods/read.rb:28:in `define_method_attribute' from activerecord/lib/active_record/attribute_methods/primary_key.rb:61:in `define_method_attribute' from activemodel/lib/active_model/attribute_methods.rb:292:in `block in define_attribute_method' from activemodel/lib/active_model/attribute_methods.rb:285:in `each' from activemodel/lib/active_model/attribute_methods.rb:285:in `define_attribute_method' This patch contains both a fix in Active Model and a test in Active Record for this error.
-
由 Kasper Timm Hansen 提交于
``` Minitest.run_via[:rails] = true ```
👆 would break because a simple alias won't catch the second true argument there. -
由 Guillermo Iguaran 提交于
Use Puma 3.7
-
由 Vipul A M 提交于
Fix some grammar in docs [ci skip]
-
由 kenta-s 提交于
-
由 Guillermo Iguaran 提交于
Use `response#location` instead of `#location` in redirect.
-
由 Roberto Miranda 提交于
ref this commit seems that has not been merged into 3.7 https://github.com/puma/puma/commit/42bec4600c51ab8a1c1ee5a0e1b738a4ffd82bf2
-
由 Matthew Draper 提交于
Ensure test threads share a DB connection
-
由 Jon Moss 提交于
[ci skip]
-
由 eileencodes 提交于
-
由 Eileen M. Uchitelle 提交于
WIP: Capybara Integration with Rails (AKA System Tests)
-
由 eileencodes 提交于
This ensures multiple threads inside a transactional test to see consistent database state. When a system test starts Puma spins up one thread and Capybara spins up another thread. Because of this when tests are run the database cannot see what was inserted into the database on teardown. This is because there are two threads using two different connections. This change uses the statement cache to lock the threads to using a single connection ID instead of each not being able to see each other. This code only runs in the fixture setup and teardown so it does not affect real production databases. When a transaction is opened we set `lock_thread` to `Thread.current` so we can keep track of which connection the thread is using. When we rollback the transaction we unlock the thread and then there will be no left-over data in the database because the transaction will roll back the correct connections. [ Eileen M. Uchitelle, Matthew Draper ]
-
由 Kasper Timm Hansen 提交于
Prevent multiple values being set to `run_via`
-
由 Kasper Timm Hansen 提交于
Pointed out by @matthewd that the HWIA subclass changes the AS scoped class and top-level HWIA hierarchies out from under existing classes. This reverts commit 71da3909, reversing changes made to 41c33bd4.
-
由 eileencodes 提交于
There were some grammar issues and incorrect information in the system tests documentation.
-
由 eileencodes 提交于
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.
-
由 eileencodes 提交于
* Override integration test default host Integration tests automatically set the default host to 'http://example.com'. This works fine for integration tests because they are not real browser sessions, but doesn't work fine for system tests because they are real browser sessions. We can override this by setting the `host!` in `before_setup. The `Capybara.always_include_port` will allow the test to look at `127.0.0.1:port capybara picks` and properly redirect the test. Any application can override this by setting the `host!` in their system test helper. Generally though, applications are going to be using localhost. In this commit I also moved the setup and teardown into their own module for tidiness. * Move teardown settings into system test case These configuration options can be put into the system test case file instead of the generated system tests helper file. This is an implementation detail and therefore shouldn't be generated with the template.
-
由 eileencodes 提交于
We only want the file name to include the word `failures` if it failed, not any time the user wants to take a screenshot during a test run.
-
由 eileencodes 提交于
This serves as self documentation so users know how to change the driver.
-
由 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 提交于
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.
-
由 eileencodes 提交于
Update the documentation after rewriting a majority of the functionality for system testing.
-
由 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.
-
由 eileencodes 提交于
This adds the required guides for how to write and use system tests in your application.
-
由 eileencodes 提交于
1. Clean up screenshot helper Updates documentation to be clearer and separates the concerns of saving the image, setting the image path, and displaying the image. 2. Remove Rails provided assertions for selectors This was moved upstream to Capybara and is no longer necessary to be included in Rails 3. Remove form helper The form helper is pretty specific to Basecamp's needs and may not be helpful outside of Rails.
-
由 eileencodes 提交于
Since I've moved the teardown code that contains the screenshot handling to be generated when the application is generated this code was interfering with the screenshot taking. Because this runs before any app teardown code we would be resetting sessions before taking the screenshot, resulting in a blank browser window. The code to reset the sessions must come AFTER a screenshot has been taken.
-
由 eileencodes 提交于
-
由 eileencodes 提交于
If this is not set Webrick will log **everything** to STDOUT and distract from the running tests. This will instead log to the log file. This example was extracted from the Capybara source code.
-
由 eileencodes 提交于
Call doesn't make as much sense here, we're really starting to run the driver.
-
由 eileencodes 提交于
Many changes have been made since the beginning so documentation needed a refresher.
-
由 eileencodes 提交于
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.
-
由 eileencodes 提交于
By moving to the TestUnit Railtie, and doing the file requirement inside the onload call we can avoid loading ActionSystemTest in production and load it in the test env. This is important for performance reasons - loading up unnecessary files and object is expensive, especially when they should never be used in production.
-
由 eileencodes 提交于
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.
-
由 eileencodes 提交于
Rubocop / code climate don't like single quotes and prefer doubles.
-
由 eileencodes 提交于
Puma is the default webserver of Rails. Because of this it doesn't make sense to run tests in Webkit if the default server is Puma. Here I've refactored the webserver to be it's own standalone module so it can be shared between Rails' selenium default driver and Capybara's defaut drivers.
-
由 eileencodes 提交于
This change adds support, tests, and documentation for the screenshot helper. If taking screenshots is supported by the driver (for example Rack Test doesn't support screenshots) then a screenshot will be taken if the test fails.
-
由 eileencodes 提交于
This removes the useless Rack Test Driver that Rails was providing and moves to a shim like approach for default adapters. If someone wants to use one of the default Capybara Drivers then we will initialize a new `CapybaraDriver` that simply sets the default driver. Rails though is much more opinionated than Capybara and to make system testing a "works out of the box" framework in Rails we have the `RailsSeleniumDriver`. This driver sets defaults that Rails deems important for selenium testing. The purpose of this is to simply add a test and it just works.
-
由 eileencodes 提交于
* Document Rails::SystemTestCase * Document setting drivers with the configration options * Document using the getter/setter for driver adapters * Document the CapybaraRackTestDriver and defaults * Document the CapybaraSeleniumDriver and defaults * Document custom assertions provided by System Testing * Document custom form helpers provided by System Testing
-
由 eileencodes 提交于
* Adds test case test * Adds driver adapter test * Adds tests for capybara seleium driver (testing the settings not actually opening the browser to test capybara w/ selenium because that would so so so slow) * Adds tests for rack test driver * Adds tests for generators
-
由 eileencodes 提交于
This will clean up the railtie quite a bit, rather than passing a set of hash keys call the new class directly like we do with ActiveJob. Only call driver once when tests start rather than in every single test setup. This is more performant, and the other way was creating unnecessary calls.
-