在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):teamcapybara/capybara开源软件地址(OpenSource Url):https://github.com/teamcapybara/capybara开源编程语言(OpenSource Language):Ruby 92.4%开源软件介绍(OpenSource Introduction):CapybaraCapybara helps you test web applications by simulating how a real user would interact with your app. It is agnostic about the driver running your tests and comes with Rack::Test and Selenium support built in. WebKit is supported through an external gem. Support CapybaraIf you and/or your company find value in Capybara and would like to contribute financially to its ongoing maintenance and development, please visit Patreon Need help? Ask on the mailing list (please do not open an issue on GitHub): http://groups.google.com/group/ruby-capybara Table of contents
Key benefits
SetupCapybara requires Ruby 2.7.0 or later. To install, add this line to your
gem 'capybara' If the application that you are testing is a Rails app, add this line to your test helper file: require 'capybara/rails' If the application that you are testing is a Rack app, but not Rails, set Capybara.app to your Rack app: Capybara.app = MyRackApp If you need to test JavaScript, or if your app interacts with (or is located at) a remote URL, you'll need to use a different driver. If using Rails 5.0+, but not using the Rails system tests from 5.1, you'll probably also want to swap the "server" used to launch your app to Puma in order to match Rails defaults. Capybara.server = :puma # Until your setup is working
Capybara.server = :puma, { Silent: true } # To clean up your test output Using Capybara with CucumberThe require 'capybara/cucumber'
Capybara.app = MyRackApp You can use the Capybara DSL in your steps, like so: When /I sign in/ do
within("#session") do
fill_in 'Email', with: '[email protected]'
fill_in 'Password', with: 'password'
end
click_button 'Sign in'
end You can switch to the @javascript
Scenario: do something Ajaxy
When I click the Ajax link
... There are also explicit tags for each registered driver set up for you ( Using Capybara with RSpecLoad RSpec 3.5+ support by adding the following line (typically to your
require 'capybara/rspec' If you are using Rails, put your Capybara specs in If you are using Rails system specs please see their documentation for selecting the driver you wish to use. If you are not using Rails, tag all the example groups in which you want to use
Capybara with You can now write your specs like so: describe "the signin process", type: :feature do
before :each do
User.create(email: '[email protected]', password: 'password')
end
it "signs me in" do
visit '/sessions/new'
within("#session") do
fill_in 'Email', with: '[email protected]'
fill_in 'Password', with: 'password'
end
click_button 'Sign in'
expect(page).to have_content 'Success'
end
end Use describe 'some stuff which requires js', js: true do
it 'will use the default js driver'
it 'will switch to one specific driver', driver: :apparition
end Capybara also comes with a built in DSL for creating descriptive acceptance tests: feature "Signing in" do
background do
User.create(email: '[email protected]', password: 'caplin')
end
scenario "Signing in with correct credentials" do
visit '/sessions/new'
within("#session") do
fill_in 'Email', with: '[email protected]'
fill_in 'Password', with: 'caplin'
end
click_button 'Sign in'
expect(page).to have_content 'Success'
end
given(:other_user) { User.create(email: '[email protected]', password: 'rous') }
scenario "Signing in as another user" do
visit '/sessions/new'
within("#session") do
fill_in 'Email', with: other_user.email
fill_in 'Password', with: other_user.password
end
click_button 'Sign in'
expect(page).to have_content 'Invalid email or password'
end
end
Finally, Capybara matchers are also supported in view specs: RSpec.describe "todos/show.html.erb", type: :view do
it "displays the todo title" do
assign :todo, Todo.new(title: "Buy milk")
render
expect(rendered).to have_css("header h1", text: "Buy milk")
end
end Note: When you require 'capybara/rspec' proxy methods are installed to work around name collisions between Capybara::DSL methods
Using Capybara with Test::Unit
Using Capybara with Minitest
To switch the driver, set class BlogTest < ActionDispatch::IntegrationTest
setup do
Capybara.current_driver = Capybara.javascript_driver # :selenium by default
end
test 'shows blog posts' do
# ... this test is run with Selenium ...
end
end Using Capybara with Minitest::SpecFollow the above instructions for Minitest and additionally require capybara/minitest/spec page.must_have_content('Important!') DriversCapybara uses the same DSL to drive a variety of browser and headless drivers. Selecting the DriverBy default, Capybara uses the Capybara.default_driver = :selenium # :selenium_chrome and :selenium_chrome_headless are also registered However, if you are using RSpec or Cucumber (and your app runs correctly without JS),
you may instead want to consider leaving the faster You can also change the driver temporarily (typically in the Before/setup and After/teardown blocks): Capybara.current_driver = :apparition # temporarily select different driver
# tests here
Capybara.use_default_driver # switch back to default driver Note: switching the driver creates a new session, so you may not be able to switch in the middle of a test. RackTestRackTest is Capybara's default driver. It is written in pure Ruby and does not have any support for executing JavaScript. Since the RackTest driver interacts directly with Rack interfaces, it does not require a server to be started. However, this means that if your application is not a Rack application (Rails, Sinatra and most other Ruby frameworks are Rack applications) then you cannot use this driver. Furthermore, you cannot use the RackTest driver to test a remote application, or to access remote URLs (e.g., redirects to external sites, external APIs, or OAuth services) that your application might interact with. capybara-mechanize provides a similar driver that can access remote servers. RackTest can be configured with a set of headers like this: Capybara.register_driver :rack_test do |app|
Capybara::RackTest::Driver.new(app, headers: { 'HTTP_USER_AGENT' => 'Capybara' })
end See the section on adding and configuring drivers. SeleniumCapybara supports Selenium 3.5+
(Webdriver).
In order to use Selenium, you'll need to install the Capybara pre-registers a number of named drivers that use Selenium - they are:
These should work (with relevant software installation) in a local desktop configuration but you may need to customize them if using in a CI environment where additional options may need to be passed to the browsers. See the section on adding and configuring drivers. Note: drivers which run the server in a different thread may not share the same transaction as your tests, causing data not to be shared between your test and test server, see Transactions and database setup below. ApparitionThe apparition driver is a new driver that allows you to run tests using Chrome in a headless or headed configuration. It attempts to provide backwards compatibility with the Poltergeist driver API and capybara-webkit API while allowing for the use of modern JS/CSS. It uses CDP to communicate with Chrome, thereby obviating the need for chromedriver. This driver is being developed by the current developer of Capybara and will attempt to keep up to date with new Capybara releases. It will probably be moved into the teamcapybara repo once it reaches v1.0. The DSLA complete reference is available at rubydoc.info. Note: By default Capybara will only locate visible elements. This is because a real user would not be able to interact with non-visible elements. Note: All searches in Capybara are case sensitive. This is because Capybara heavily uses XPath, which doesn't support case insensitivity. NavigatingYou can use the visit method to navigate to other pages: visit('/projects')
visit(post_comments_path(post)) The visit method only takes a single parameter, the request method is always GET. You can get the current path
of the browsing session, and test it using the expect(page).to have_current_path(post_comments_path(post)) Note: You can also assert the current path by testing the value of
Clicking links and buttonsFull reference: Capybara::Node::Actions You can interact with the webapp by following links and buttons. Capybara automatically follows any redirects, and submits forms associated with buttons. click_link('id-of-link')
click_link('Link Text')
click_button('Save')
click_on('Link Text') # clicks on either links or buttons
click_on('Button Value') Interacting with formsFull reference: Capybara::Node::Actions There are a number of tools for interacting with form elements: fill_in('First Name', with: 'John')
fill_in('Password', with: 'Seekrit')
fill_in('Description', with: 'Really Long Text...')
choose('A Radio Button')
check('A Checkbox')
uncheck('A Checkbox')
attach_file('Image', '/path/to/image.jpg')
select('Option', from: 'Select Box') QueryingFull reference: Capybara::Node::Matchers Capybara has a rich set of options for querying the page for the existence of certain elements, and working with and manipulating those elements. page.has_selector?('table tr')
page.has_selector?(:xpath, './/table/tr')
page.has_xpath?('.//table/tr')
page.has_css?('table tr.foo')
page.has_content?('foo') Note: The negative forms like You can use these with RSpec's magic matchers: expect(page).to have_selector('table tr')
expect(page).to have_selector(:xpath, './/table/tr')
expect(page).to have_xpath('.//table/tr')
expect(page).to have_css('table tr.foo')
expect(page).to have_content('foo') FindingFull reference: Capybara::Node::Finders You can also find specific elements, in order to manipulate them: find_field('First Name').value
find_field(id: 'my_field').value
find_link('Hello', :visible => :all).visible?
find_link(class: ['some_class', 'some_other_class'], :visible => :all).visible?
find_button('Send').click
find_button(value: '1234').click
find(:xpath, ".//table/tr").click
find("#overlay").find("h1").click
all('a').each { |a| a[:href] } |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论