mirror of
https://github.com/discourse/discourse.git
synced 2024-11-26 20:33:38 +08:00
e323628d8a
What is the problem? We are relying on RSpec custom matchers in system tests by defining predicates in page objects. The problem is that this can result in a system test unnecessarily waiting up till the full duration of Capybara's default wait time when the RSpec custom matcher is used with `not_to`. Considering this topic page object where we have a `has_post?` predicate defined. ``` class Topic < PageObject def has_post? has_css?('something') end end ``` The assertion `expect(Topic.new).not_to have_post` will end up waiting the full Capybara's default wait time since the RSpec custom matcher is calling Capybara's `has_css?` method which will wait until the selector appear. If the selector has already disappeared by the time the assertion is called, we end up waiting for something that will never exists. This commit fixes such cases by introducing new predicates that uses the `has_no_*` versions of Capybara's node matchers. For future reference, `to have_css` and `not_to have_css` is safe to sue because the RSpec matcher defined by Capbyara is smart enough to call `has_css?` or `has_no_css?` based on the expectation of the assertion. |
||
---|---|---|
.. | ||
composer | ||
emojis | ||
page_objects | ||
user_page | ||
admin_customize_form_templates_spec.rb | ||
admin_customize_themes_spec.rb | ||
bookmarks_spec.rb | ||
category_edit_spec.rb | ||
custom_sidebar_sections_spec.rb | ||
discovery_breadcrumb_navigation_spec.rb | ||
ember_deprecation_test.rb | ||
fast_edit_spec.rb | ||
filtering_topics_spec.rb | ||
hashtag_autocomplete_spec.rb | ||
search_spec.rb | ||
tag_notification_level_spec.rb | ||
tag_synonyms_spec.rb | ||
user_preferences_interface_spec.rb | ||
user_preferences_navigation_spec.rb | ||
user_selector_spec.rb | ||
viewing_category_spec.rb | ||
viewing_sidebar_mobile_spec.rb | ||
viewing_sidebar_preferences_spec.rb | ||
viewing_sidebar_spec.rb |