2019-04-29 20:27:42 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2013-02-05 14:16:51 -05:00
|
|
|
if ENV["COVERAGE"]
|
|
|
|
require "simplecov"
|
2021-03-29 14:01:35 -04:00
|
|
|
if ENV["TEST_ENV_NUMBER"]
|
|
|
|
SimpleCov.command_name "#{SimpleCov.command_name} #{ENV["TEST_ENV_NUMBER"]}"
|
2023-01-09 06:18:21 -05:00
|
|
|
end
|
2021-03-29 14:01:35 -04:00
|
|
|
SimpleCov.start "rails" do
|
|
|
|
add_group "Libraries", %r{^/lib/(?!tasks).*$}
|
|
|
|
add_group "Scripts", "script"
|
|
|
|
add_group "Serializers", "app/serializers"
|
|
|
|
add_group "Services", "app/services"
|
|
|
|
add_group "Tasks", "lib/tasks"
|
|
|
|
end
|
2013-02-05 14:16:51 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
require "rubygems"
|
2022-05-04 21:50:02 -04:00
|
|
|
require "rbtrace" if RUBY_ENGINE == "ruby"
|
2020-06-16 20:08:53 -04:00
|
|
|
require "pry"
|
|
|
|
require "pry-byebug"
|
|
|
|
require "pry-rails"
|
2017-08-09 17:50:59 -04:00
|
|
|
require "fabrication"
|
|
|
|
require "mocha/api"
|
|
|
|
require "certified"
|
|
|
|
require "webmock/rspec"
|
|
|
|
|
2018-05-21 03:01:30 -04:00
|
|
|
class RspecErrorTracker
|
|
|
|
def self.last_exception=(ex)
|
|
|
|
@ex = ex
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.last_exception
|
|
|
|
@ex
|
|
|
|
end
|
|
|
|
|
|
|
|
def initialize(app, config = {})
|
|
|
|
@app = app
|
|
|
|
end
|
|
|
|
|
|
|
|
def call(env)
|
|
|
|
begin
|
|
|
|
@app.call(env)
|
DEV: Output webmock errors in request specs (#14782)
* DEV: Output webmock errors in request specs
In request specs, if you had not properly mocked an external
HTTP call, you would end up with a 500 error with no further
information instead of your expected response code, with an
rspec output like this:
```
Failures:
1) UploadsController#generate_presigned_put when the store is external generates a presigned URL and creates an external upload stub
Failure/Error: expect(response.status).to eq(200)
expected: 200
got: 500
(compared using ==)
# ./spec/requests/uploads_controller_spec.rb:727:in `block (4 levels) in <top (required)>'
# ./spec/rails_helper.rb:280:in `block (2 levels) in <top (required)>'
```
This is not helpful at all when you want to find what you actually
failed to mock, which is shown straight away in non-request specs.
This commit introduces a rescue_from block in the application
controller to log this error, so we have a much nicer output that
helps the developer find the issue:
```
Failures:
1) UploadsController#generate_presigned_put when the store is external generates a presigned URL and creates an external upload stub
Failure/Error: expect(response.status).to eq(200)
expected: 200
got: 500
(compared using ==)
# ./spec/requests/uploads_controller_spec.rb:727:in `block (4 levels) in <top (required)>'
# ./spec/rails_helper.rb:280:in `block (2 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# WebMock::NetConnectNotAllowedError:
# Real HTTP connections are disabled. Unregistered request: GET https://s3-upload-bucket.s3.us-west-1.amazonaws.com/?cors with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'', 'Authorization'=>'AWS4-HMAC-SHA256 Credential=some key/20211101/us-west-1/s3/aws4_request, SignedHeaders=host;user-agent;x-amz-content-sha256;x-amz-date, Signature=test', 'Host'=>'s3-upload-bucket.s3.us-west-1.amazonaws.com', 'User-Agent'=>'aws-sdk-ruby3/3.121.2 ruby/2.7.1 x86_64-linux aws-sdk-s3/1.96.1', 'X-Amz-Content-Sha256'=>'test', 'X-Amz-Date'=>'20211101T035113Z'}
#
# You can stub this request with the following snippet:
#
# stub_request(:get, "https://s3-upload-bucket.s3.us-west-1.amazonaws.com/?cors").
# with(
# headers: {
# 'Accept'=>'*/*',
# 'Accept-Encoding'=>'',
# 'Authorization'=>'AWS4-HMAC-SHA256 Credential=some key/20211101/us-west-1/s3/aws4_request, SignedHeaders=host;user-agent;x-amz-content-sha256;x-amz-date, Signature=test',
# 'Host'=>'s3-upload-bucket.s3.us-west-1.amazonaws.com',
# 'User-Agent'=>'aws-sdk-ruby3/3.121.2 ruby/2.7.1 x86_64-linux aws-sdk-s3/1.96.1',
# 'X-Amz-Content-Sha256'=>'test',
# 'X-Amz-Date'=>'20211101T035113Z'
# }).
# to_return(status: 200, body: "", headers: {})
#
# registered request stubs:
#
# stub_request(:head, "https://s3-upload-bucket.s3.us-west-1.amazonaws.com/")
#
# ============================================================
```
* DEV: Require webmock in application controller if rails.env.test
* DEV: Rescue from StandardError and NetConnectNotAllowedError
2021-11-01 02:38:41 -04:00
|
|
|
|
|
|
|
# This is a little repetitive, but since WebMock::NetConnectNotAllowedError
|
2021-11-11 22:10:16 -05:00
|
|
|
# and also Mocha::ExpectationError inherit from Exception instead of StandardError
|
|
|
|
# they do not get captured by the rescue => e shorthand :(
|
|
|
|
rescue WebMock::NetConnectNotAllowedError, Mocha::ExpectationError, StandardError => e
|
2018-05-21 03:01:30 -04:00
|
|
|
RspecErrorTracker.last_exception = e
|
|
|
|
raise e
|
|
|
|
end
|
|
|
|
ensure
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
ENV["RAILS_ENV"] ||= "test"
|
|
|
|
require File.expand_path("../../config/environment", __FILE__)
|
|
|
|
require "rspec/rails"
|
2019-04-17 17:41:37 -04:00
|
|
|
require "shoulda-matchers"
|
2017-08-09 17:50:59 -04:00
|
|
|
require "sidekiq/testing"
|
2019-05-06 23:12:20 -04:00
|
|
|
require "test_prof/recipes/rspec/let_it_be"
|
|
|
|
require "test_prof/before_all/adapters/active_record"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
require "webdrivers"
|
|
|
|
require "selenium-webdriver"
|
|
|
|
require "capybara/rails"
|
2017-08-09 17:50:59 -04:00
|
|
|
|
2019-04-17 17:41:37 -04:00
|
|
|
# The shoulda-matchers gem no longer detects the test framework
|
|
|
|
# you're using or mixes itself into that framework automatically.
|
|
|
|
Shoulda::Matchers.configure do |config|
|
|
|
|
config.integrate do |with|
|
|
|
|
with.test_framework :rspec
|
|
|
|
with.library :active_record
|
|
|
|
with.library :active_model
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
# Requires supporting ruby files with custom matchers and macros, etc,
|
|
|
|
# in spec/support/ and its subdirectories.
|
|
|
|
Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
|
2022-12-16 05:25:31 -05:00
|
|
|
Dir[Rails.root.join("spec/system/page_objects/**/base.rb")].each { |f| require f }
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
Dir[Rails.root.join("spec/system/page_objects/**/*.rb")].each { |f| require f }
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
Dir[Rails.root.join("spec/fabricators/*.rb")].each { |f| require f }
|
2021-12-10 15:25:26 -05:00
|
|
|
require_relative "./helpers/redis_snapshot_helper"
|
2017-08-09 17:50:59 -04:00
|
|
|
|
|
|
|
# Require plugin helpers at plugin/[plugin]/spec/plugin_helper.rb (includes symlinked plugins).
|
|
|
|
if ENV["LOAD_PLUGINS"] == "1"
|
|
|
|
Dir[Rails.root.join("plugins/*/spec/plugin_helper.rb")].each { |f| require f }
|
2021-11-29 23:55:45 -05:00
|
|
|
|
|
|
|
Dir[Rails.root.join("plugins/*/spec/fabricators/**/*.rb")].each { |f| require f }
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
|
|
|
|
Dir[Rails.root.join("plugins/*/spec/system/page_objects/**/*.rb")].each { |f| require f }
|
2017-08-09 17:50:59 -04:00
|
|
|
end
|
2017-05-18 22:38:36 -04:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
# let's not run seed_fu every test
|
|
|
|
SeedFu.quiet = true if SeedFu.respond_to? :quiet
|
2014-05-22 03:37:02 -04:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
SiteSetting.automatically_download_gravatars = false
|
2014-12-15 16:10:27 -05:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
SeedFu.seed
|
2013-02-05 14:16:51 -05:00
|
|
|
|
2019-06-02 21:33:56 -04:00
|
|
|
# we need this env var to ensure that we can impersonate in test
|
|
|
|
# this enable integration_helpers sign_in helper
|
|
|
|
ENV["DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE"] = "1"
|
|
|
|
|
2019-05-06 23:12:20 -04:00
|
|
|
module TestSetup
|
|
|
|
# This is run before each test and before each before_all block
|
|
|
|
def self.test_setup(x = nil)
|
2021-08-10 00:12:36 -04:00
|
|
|
RateLimiter.disable
|
2019-05-06 23:12:20 -04:00
|
|
|
PostActionNotifier.disable
|
|
|
|
SearchIndexer.disable
|
|
|
|
UserActionManager.disable
|
|
|
|
NotificationEmailer.disable
|
|
|
|
SiteIconManager.disable
|
2022-05-12 02:45:05 -04:00
|
|
|
WordWatcher.disable_cache
|
2019-05-06 23:12:20 -04:00
|
|
|
|
|
|
|
SiteSetting.provider.all.each { |setting| SiteSetting.remove_override!(setting.name) }
|
|
|
|
|
|
|
|
# very expensive IO operations
|
|
|
|
SiteSetting.automatically_download_gravatars = false
|
|
|
|
|
|
|
|
Discourse.clear_readonly!
|
|
|
|
Sidekiq::Worker.clear_all
|
|
|
|
|
2019-05-15 17:43:00 -04:00
|
|
|
I18n.locale = SiteSettings::DefaultsProvider::DEFAULT_LOCALE
|
2019-05-06 23:12:20 -04:00
|
|
|
|
|
|
|
RspecErrorTracker.last_exception = nil
|
|
|
|
|
|
|
|
if $test_cleanup_callbacks
|
|
|
|
$test_cleanup_callbacks.reverse_each(&:call)
|
|
|
|
$test_cleanup_callbacks = nil
|
|
|
|
end
|
|
|
|
|
2019-05-09 21:37:37 -04:00
|
|
|
# in test this is very expensive, we explicitly enable when needed
|
|
|
|
Topic.update_featured_topics = false
|
|
|
|
|
2019-05-06 23:12:20 -04:00
|
|
|
# Running jobs are expensive and most of our tests are not concern with
|
|
|
|
# code that runs inside jobs. run_later! means they are put on the redis
|
|
|
|
# queue and never processed.
|
|
|
|
Jobs.run_later!
|
2020-05-23 00:56:13 -04:00
|
|
|
|
|
|
|
# Don't track ApplicationRequests in test mode unless opted in
|
|
|
|
ApplicationRequest.disable
|
|
|
|
|
|
|
|
# Don't queue badge grant in test mode
|
|
|
|
BadgeGranter.disable_queue
|
2021-12-13 12:05:26 -05:00
|
|
|
|
|
|
|
OmniAuth.config.test_mode = false
|
2019-05-06 23:12:20 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-05-21 08:07:40 -04:00
|
|
|
TestProf::BeforeAll.configure { |config| config.before(:begin) { TestSetup.test_setup } }
|
2019-05-06 23:12:20 -04:00
|
|
|
|
2019-05-21 08:07:40 -04:00
|
|
|
if ENV["PREFABRICATION"] == "0"
|
|
|
|
module Prefabrication
|
|
|
|
def fab!(name, &blk)
|
2019-05-06 23:12:20 -04:00
|
|
|
let!(name, &blk)
|
|
|
|
end
|
|
|
|
end
|
2019-05-21 08:07:40 -04:00
|
|
|
|
|
|
|
RSpec.configure { |config| config.extend Prefabrication }
|
|
|
|
else
|
|
|
|
TestProf::LetItBe.configure { |config| config.alias_to :fab!, refind: true }
|
2019-05-06 23:12:20 -04:00
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
RSpec.configure do |config|
|
|
|
|
config.fail_fast = ENV["RSPEC_FAIL_FAST"] == "1"
|
2019-08-29 05:56:43 -04:00
|
|
|
config.silence_filter_announcements = ENV["RSPEC_SILENCE_FILTER_ANNOUNCEMENTS"] == "1"
|
2021-12-10 15:25:26 -05:00
|
|
|
config.extend RedisSnapshotHelper
|
2017-08-09 17:50:59 -04:00
|
|
|
config.include Helpers
|
|
|
|
config.include MessageBus
|
|
|
|
config.include RSpecHtmlMatchers
|
|
|
|
config.include IntegrationHelpers, type: :request
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
config.include SystemHelpers, type: :system
|
2020-01-15 05:27:12 -05:00
|
|
|
config.include WebauthnIntegrationHelpers
|
2019-01-15 21:25:42 -05:00
|
|
|
config.include SiteSettingsHelpers
|
2020-07-24 05:16:52 -04:00
|
|
|
config.include SidekiqHelpers
|
2020-09-14 07:32:25 -04:00
|
|
|
config.include UploadsHelpers
|
2021-05-26 05:41:35 -04:00
|
|
|
config.include OneboxHelpers
|
2021-10-19 07:42:29 -04:00
|
|
|
config.include FastImageHelpers
|
2017-08-09 17:50:59 -04:00
|
|
|
config.mock_framework = :mocha
|
|
|
|
config.order = "random"
|
|
|
|
config.infer_spec_type_from_file_location!
|
2013-02-05 14:16:51 -05:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
# If you're not using ActiveRecord, or you'd prefer not to run each of your
|
|
|
|
# examples within a transaction, remove the following line or assign false
|
|
|
|
# instead of true.
|
|
|
|
config.use_transactional_fixtures = true
|
2013-02-05 14:16:51 -05:00
|
|
|
|
2023-01-12 22:31:28 -05:00
|
|
|
# Sometimes you may have a large string or object that you are comparing
|
|
|
|
# with some expectation, and you want to see the full diff between actual
|
|
|
|
# and expected without rspec truncating 90% of the diff. Setting the
|
|
|
|
# max_formatted_output_length to nil disables this truncation completely.
|
|
|
|
#
|
|
|
|
# c.f. https://www.rubydoc.info/gems/rspec-expectations/RSpec/Expectations/Configuration#max_formatted_output_length=-instance_method
|
|
|
|
if ENV["RSPEC_DISABLE_DIFF_TRUNCATION"]
|
|
|
|
config.expect_with :rspec do |expectation|
|
|
|
|
expectation.max_formatted_output_length = nil
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
# If true, the base class of anonymous controllers will be inferred
|
|
|
|
# automatically. This will be the default behavior in future versions of
|
|
|
|
# rspec-rails.
|
|
|
|
config.infer_base_class_for_anonymous_controllers = true
|
2013-02-05 14:16:51 -05:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
config.before(:suite) do
|
2022-02-22 11:45:25 -05:00
|
|
|
CachedCounting.disable
|
|
|
|
|
2019-12-13 07:50:18 -05:00
|
|
|
begin
|
|
|
|
ActiveRecord::Migration.check_pending!
|
|
|
|
rescue ActiveRecord::PendingMigrationError
|
|
|
|
raise "There are pending migrations, run RAILS_ENV=test bin/rake db:migrate"
|
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
Sidekiq.error_handlers.clear
|
2014-07-31 04:46:02 -04:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
# Ugly, but needed until we have a user creator
|
|
|
|
User.skip_callback(:create, :after, :ensure_in_trust_level_group)
|
2014-06-16 20:46:30 -04:00
|
|
|
|
2020-05-13 07:25:34 -04:00
|
|
|
DiscoursePluginRegistry.reset! if ENV["LOAD_PLUGINS"] != "1"
|
2017-08-09 17:50:59 -04:00
|
|
|
Discourse.current_user_provider = TestCurrentUserProvider
|
2014-03-28 01:34:20 -04:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
SiteSetting.refresh!
|
2014-03-28 01:34:20 -04:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
# Rebase defaults
|
|
|
|
#
|
|
|
|
# We nuke the DB storage provider from site settings, so need to yank out the existing settings
|
|
|
|
# and pretend they are default.
|
|
|
|
# There are a bunch of settings that are seeded, they must be loaded as defaults
|
|
|
|
SiteSetting.current.each do |k, v|
|
|
|
|
# skip setting defaults for settings that are in unloaded plugins
|
|
|
|
SiteSetting.defaults.set_regardless_of_locale(k, v) if SiteSetting.respond_to? k
|
|
|
|
end
|
2014-03-28 01:34:20 -04:00
|
|
|
|
2020-08-18 09:38:30 -04:00
|
|
|
SiteSetting.provider = TestLocalProcessProvider.new
|
2017-05-26 03:19:09 -04:00
|
|
|
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
WebMock.disable_net_connect!(allow_localhost: true, allow: [Webdrivers::Chromedriver.base_url])
|
|
|
|
|
2023-01-04 19:50:35 -05:00
|
|
|
if ENV["CAPBYARA_DEFAULT_MAX_WAIT_TIME"].present?
|
|
|
|
Capybara.default_max_wait_time = ENV["CAPBYARA_DEFAULT_MAX_WAIT_TIME"].to_i
|
|
|
|
end
|
|
|
|
|
2023-01-02 09:17:21 -05:00
|
|
|
Capybara.threadsafe = true
|
2023-02-01 10:39:23 -05:00
|
|
|
Capybara.disable_animation = false
|
2022-12-22 19:04:41 -05:00
|
|
|
|
2023-02-23 02:01:39 -05:00
|
|
|
# Click offsets is calculated from top left of element
|
|
|
|
Capybara.w3c_click_offset = false
|
|
|
|
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
Capybara.configure do |capybara_config|
|
|
|
|
capybara_config.server_host = "localhost"
|
2022-12-27 21:06:50 -05:00
|
|
|
capybara_config.server_port = 31_337 + ENV["TEST_ENV_NUMBER"].to_i
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
|
|
|
|
2023-01-24 06:07:29 -05:00
|
|
|
module IgnoreUnicornCapturedErrors
|
|
|
|
def raise_server_error!
|
|
|
|
super
|
|
|
|
rescue EOFError, Errno::ECONNRESET, Errno::EPIPE, Errno::ENOTCONN => e
|
|
|
|
# Ignore these exceptions - caused by client. Handled by unicorn in dev/prod
|
|
|
|
# https://github.com/defunkt/unicorn/blob/d947cb91cf/lib/unicorn/http_server.rb#L570-L573
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
Capybara::Session.class_eval { prepend IgnoreUnicornCapturedErrors }
|
|
|
|
|
2023-01-05 01:41:22 -05:00
|
|
|
# The valid values for SELENIUM_BROWSER_LOG_LEVEL are:
|
|
|
|
#
|
|
|
|
# OFF
|
|
|
|
# SEVERE
|
|
|
|
# WARNING
|
|
|
|
# INFO
|
|
|
|
# DEBUG
|
|
|
|
# ALL
|
|
|
|
browser_log_level = ENV["SELENIUM_BROWSER_LOG_LEVEL"] || "SEVERE"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
chrome_browser_options =
|
|
|
|
Selenium::WebDriver::Chrome::Options
|
2023-01-05 01:41:22 -05:00
|
|
|
.new(logging_prefs: { "browser" => browser_log_level, "driver" => "ALL" })
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
.tap do |options|
|
|
|
|
options.add_argument("--window-size=1400,1400")
|
|
|
|
options.add_argument("--no-sandbox")
|
|
|
|
options.add_argument("--disable-dev-shm-usage")
|
2022-12-22 09:03:03 -05:00
|
|
|
options.add_argument("--mute-audio")
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
Capybara.register_driver :selenium_chrome do |app|
|
2023-02-13 20:38:41 -05:00
|
|
|
Capybara::Selenium::Driver.new(app, browser: :chrome, options: chrome_browser_options)
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
Capybara.register_driver :selenium_chrome_headless do |app|
|
|
|
|
chrome_browser_options.add_argument("--headless")
|
|
|
|
|
2023-02-13 20:38:41 -05:00
|
|
|
Capybara::Selenium::Driver.new(app, browser: :chrome, options: chrome_browser_options)
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
2021-12-07 13:26:35 -05:00
|
|
|
|
2022-12-11 17:12:33 -05:00
|
|
|
mobile_chrome_browser_options =
|
|
|
|
Selenium::WebDriver::Chrome::Options
|
2022-12-22 11:47:33 -05:00
|
|
|
.new(logging_prefs: { "browser" => "INFO", "driver" => "ALL" })
|
2022-12-11 17:12:33 -05:00
|
|
|
.tap do |options|
|
|
|
|
options.add_argument("--window-size=390,950")
|
|
|
|
options.add_argument("--no-sandbox")
|
|
|
|
options.add_argument("--disable-dev-shm-usage")
|
|
|
|
options.add_emulation(device_name: "iPhone 12 Pro")
|
2022-12-22 09:03:03 -05:00
|
|
|
options.add_argument("--mute-audio")
|
2022-12-11 17:12:33 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
Capybara.register_driver :selenium_mobile_chrome do |app|
|
2023-02-13 20:38:41 -05:00
|
|
|
Capybara::Selenium::Driver.new(app, browser: :chrome, options: mobile_chrome_browser_options)
|
2022-12-11 17:12:33 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
Capybara.register_driver :selenium_mobile_chrome_headless do |app|
|
|
|
|
mobile_chrome_browser_options.add_argument("--headless")
|
2023-02-13 20:38:41 -05:00
|
|
|
Capybara::Selenium::Driver.new(app, browser: :chrome, options: mobile_chrome_browser_options)
|
2022-12-11 17:12:33 -05:00
|
|
|
end
|
|
|
|
|
2021-12-07 13:26:35 -05:00
|
|
|
if ENV["ELEVATED_UPLOADS_ID"]
|
|
|
|
DB.exec "SELECT setval('uploads_id_seq', 10000)"
|
|
|
|
else
|
|
|
|
DB.exec "SELECT setval('uploads_id_seq', 1)"
|
|
|
|
end
|
2017-08-09 17:50:59 -04:00
|
|
|
end
|
2014-03-28 01:34:20 -04:00
|
|
|
|
2020-08-18 09:38:30 -04:00
|
|
|
class TestLocalProcessProvider < SiteSettings::LocalProcessProvider
|
|
|
|
attr_accessor :current_site
|
|
|
|
|
|
|
|
def initialize
|
|
|
|
super
|
|
|
|
self.current_site = "test"
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
config.after :each do |example|
|
|
|
|
if example.exception && ex = RspecErrorTracker.last_exception
|
2018-05-21 03:01:30 -04:00
|
|
|
# magic in a cause if we have none
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
unless example.exception.cause
|
|
|
|
class << example.exception
|
2018-05-21 03:01:30 -04:00
|
|
|
attr_accessor :cause
|
|
|
|
end
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
example.exception.cause = ex
|
2018-05-21 03:01:30 -04:00
|
|
|
end
|
|
|
|
end
|
2018-06-11 23:43:41 -04:00
|
|
|
|
|
|
|
unfreeze_time
|
2018-08-21 02:29:58 -04:00
|
|
|
ActionMailer::Base.deliveries.clear
|
2018-07-10 21:54:01 -04:00
|
|
|
|
2019-01-08 21:53:38 -05:00
|
|
|
if ActiveRecord::Base.connection_pool.stat[:busy] > 1
|
|
|
|
raise ActiveRecord::Base.connection_pool.stat.inspect
|
|
|
|
end
|
2018-05-21 03:01:30 -04:00
|
|
|
end
|
|
|
|
|
2020-05-18 19:09:36 -04:00
|
|
|
config.after(:suite) do
|
|
|
|
FileUtils.remove_dir(file_from_fixtures_tmp_folder, true) if SpecSecureRandom.value
|
|
|
|
end
|
|
|
|
|
2019-05-06 23:12:20 -04:00
|
|
|
config.before :each, &TestSetup.method(:test_setup)
|
2013-02-05 14:16:51 -05:00
|
|
|
|
2020-11-11 14:46:13 -05:00
|
|
|
config.around :each do |example|
|
|
|
|
before_event_count = DiscourseEvent.events.values.sum(&:count)
|
|
|
|
example.run
|
|
|
|
after_event_count = DiscourseEvent.events.values.sum(&:count)
|
|
|
|
expect(before_event_count).to eq(after_event_count),
|
|
|
|
"DiscourseEvent registrations were not cleaned up"
|
|
|
|
end
|
|
|
|
|
2020-12-07 19:03:31 -05:00
|
|
|
config.before :each do
|
|
|
|
# This allows DB.transaction_open? to work in tests. See lib/mini_sql_multisite_connection.rb
|
|
|
|
DB.test_transaction = ActiveRecord::Base.connection.current_transaction
|
|
|
|
end
|
|
|
|
|
2021-11-11 11:44:58 -05:00
|
|
|
# Match the request hostname to the value in `database.yml`
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
config.before(:all, type: %i[request multisite system]) { host! "test.localhost" }
|
|
|
|
config.before(:each, type: %i[request multisite system]) { host! "test.localhost" }
|
|
|
|
|
|
|
|
last_driven_by = nil
|
|
|
|
config.before(:each, type: :system) do |example|
|
|
|
|
if example.metadata[:js]
|
2022-12-11 17:12:33 -05:00
|
|
|
driver = [:selenium]
|
|
|
|
driver << :mobile if example.metadata[:mobile]
|
|
|
|
driver << :chrome
|
|
|
|
driver << :headless unless ENV["SELENIUM_HEADLESS"] == "0"
|
|
|
|
driven_by driver.join("_").to_sym
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
|
|
|
setup_system_test
|
|
|
|
end
|
|
|
|
|
|
|
|
config.after(:each, type: :system) do |example|
|
2022-12-28 05:47:57 -05:00
|
|
|
lines = RSpec.current_example.metadata[:extra_failure_lines]
|
|
|
|
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
# This is disabled by default because it is super verbose,
|
|
|
|
# if you really need to dig into how selenium is communicating
|
|
|
|
# for system tests then enable it.
|
|
|
|
if ENV["SELENIUM_VERBOSE_DRIVER_LOGS"]
|
2022-12-28 05:47:57 -05:00
|
|
|
lines << "~~~~~~~ DRIVER LOGS ~~~~~~~"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
page.driver.browser.logs.get(:driver).each { |log| lines << log.message }
|
2022-12-28 05:47:57 -05:00
|
|
|
lines << "~~~~~ END DRIVER LOGS ~~~~~"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
# Recommended that this is not disabled, since it makes debugging
|
|
|
|
# failed system tests a lot trickier.
|
|
|
|
if ENV["SELENIUM_DISABLE_VERBOSE_JS_LOGS"].blank?
|
|
|
|
if example.exception
|
|
|
|
skip_js_errors = false
|
2022-12-28 05:47:57 -05:00
|
|
|
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
if example.exception.kind_of?(RSpec::Core::MultipleExceptionError)
|
2022-12-28 05:47:57 -05:00
|
|
|
lines << "~~~~~~~ SYSTEM TEST ERRORS ~~~~~~~"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
example.exception.all_exceptions.each { |ex| lines << ex.message }
|
2022-12-28 05:47:57 -05:00
|
|
|
lines << "~~~~~ END SYSTEM TEST ERRORS ~~~~~"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
|
|
|
|
skip_js_errors = true
|
|
|
|
end
|
|
|
|
|
|
|
|
if !skip_js_errors
|
2022-12-28 05:47:57 -05:00
|
|
|
lines << "~~~~~~~ JS LOGS ~~~~~~~"
|
|
|
|
logs = page.driver.browser.logs.get(:browser)
|
|
|
|
if logs.empty?
|
|
|
|
lines << "(no logs)"
|
|
|
|
else
|
|
|
|
logs.each { |log| lines << log.message }
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
2022-12-28 05:47:57 -05:00
|
|
|
lines << "~~~~~ END JS LOGS ~~~~~"
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2022-12-11 18:53:39 -05:00
|
|
|
|
|
|
|
Discourse.redis.flushdb
|
DEV: Minimal first pass of rails system test setup (#16311)
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the `webdrivers` gem and `selenium-webdriver` which is what
the latest Rails uses so the tests run locally and in CI out of the box.
You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra
verbose logs of what selenium is doing to communicate with the system
tests.
By default JS logs are verbose so errors from JS are shown when
running system tests, you can disable this with
`SELENIUM_DISABLE_VERBOSE_JS_LOGS=1`
You can use `SELENIUM_HEADLESS=0` to run the system
tests inside a chrome browser instead of headless, which can be useful to debug things
and see what the spec sees. See note above about `bin/ember-cli` to avoid
surprises.
I have modified `bin/turbo_rspec` to exclude `spec/system` by default,
support for parallel system specs is a little shaky right now and we don't
want them slowing down the turbo by default either.
### PageObjects and System Tests
To make querying and inspecting parts of the page easier
and more reusable inbetween system tests, we are using the
concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in
our system tests. A "Page" here is generally corresponds to
an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`,
and this contains logic for querying components within the topic
such as "Posts".
I have also split "Modals" into their own entity. Further down the
line we may want to explore creating independent "Component"
contexts.
Capybara DSL should be included in each PageObject class,
reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl
For system tests, since they are so slow, we want to focus on
the "happy path" and not do every different possible context
and branch check using them. They are meant to be overarching
tests that check a number of things are correct using the full stack
from JS and ember to rails to ruby and then the database.
### CI Setup
Whenever a system spec fails, a screenshot
is taken and a build artifact is produced _after the entire CI run is complete_,
which can be downloaded from the Actions UI in the repo.
Most importantly, a step to build the Ember app using Ember CLI
is needed, otherwise the JS assets cannot be found by capybara:
```
- name: Build Ember CLI
run: bin/ember-cli --build
```
A new `--build` argument has been added to `bin/ember-cli` for this
case, which is not needed locally if you already have the discourse
rails server running via `bin/ember-cli -u` since the whole server is built and
set up by default.
Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
|
|
|
end
|
2021-11-11 11:44:58 -05:00
|
|
|
|
2018-09-10 22:15:06 -04:00
|
|
|
config.before(:each, type: :multisite) do
|
2020-03-26 11:32:41 -04:00
|
|
|
Rails.configuration.multisite = true # rubocop:disable Discourse/NoDirectMultisiteManipulation
|
2019-01-14 23:52:12 -05:00
|
|
|
|
2018-09-10 22:15:06 -04:00
|
|
|
RailsMultisite::ConnectionManagement.config_filename = "spec/fixtures/multisite/two_dbs.yml"
|
2020-04-15 11:42:48 -04:00
|
|
|
|
|
|
|
RailsMultisite::ConnectionManagement.establish_connection(db: "default")
|
2018-09-10 22:15:06 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
config.after(:each, type: :multisite) do
|
2019-01-14 23:52:12 -05:00
|
|
|
ActiveRecord::Base.clear_all_connections!
|
2020-03-26 11:32:41 -04:00
|
|
|
Rails.configuration.multisite = false # rubocop:disable Discourse/NoDirectMultisiteManipulation
|
2018-09-10 22:15:06 -04:00
|
|
|
RailsMultisite::ConnectionManagement.clear_settings!
|
|
|
|
ActiveRecord::Base.establish_connection
|
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
class TestCurrentUserProvider < Auth::DefaultCurrentUserProvider
|
2018-11-12 09:34:12 -05:00
|
|
|
def log_on_user(user, session, cookies, opts = {})
|
2017-08-09 17:50:59 -04:00
|
|
|
session[:current_user_id] = user.id
|
|
|
|
super
|
2017-07-24 09:17:42 -04:00
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
def log_off_user(session, cookies)
|
|
|
|
session[:current_user_id] = nil
|
|
|
|
super
|
2017-02-15 10:58:18 -05:00
|
|
|
end
|
2017-08-09 17:50:59 -04:00
|
|
|
end
|
2017-02-15 10:58:18 -05:00
|
|
|
|
2019-01-09 15:13:02 -05:00
|
|
|
# Normally we `use_transactional_fixtures` to clear out a database after a test
|
|
|
|
# runs. However, this does not apply to tests done for multisite. The second time
|
|
|
|
# a test runs you can end up with stale data that breaks things. This method will
|
|
|
|
# force a rollback after using a multisite connection.
|
|
|
|
def test_multisite_connection(name)
|
|
|
|
RailsMultisite::ConnectionManagement.with_connection(name) do
|
2019-08-01 10:25:59 -04:00
|
|
|
ActiveRecord::Base.transaction(joinable: false) do
|
|
|
|
yield
|
|
|
|
raise ActiveRecord::Rollback
|
2019-01-09 15:13:02 -05:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2017-08-09 17:50:59 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
class TrackTimeStub
|
|
|
|
def self.stubbed
|
|
|
|
false
|
2017-07-24 09:17:42 -04:00
|
|
|
end
|
2017-08-09 17:50:59 -04:00
|
|
|
end
|
|
|
|
|
2017-10-06 01:20:01 -04:00
|
|
|
def before_next_spec(&callback)
|
|
|
|
($test_cleanup_callbacks ||= []) << callback
|
|
|
|
end
|
|
|
|
|
|
|
|
def global_setting(name, value)
|
|
|
|
GlobalSetting.reset_s3_cache!
|
|
|
|
|
|
|
|
GlobalSetting.stubs(name).returns(value)
|
|
|
|
|
|
|
|
before_next_spec { GlobalSetting.reset_s3_cache! }
|
|
|
|
end
|
|
|
|
|
|
|
|
def set_cdn_url(cdn_url)
|
|
|
|
global_setting :cdn_url, cdn_url
|
|
|
|
Rails.configuration.action_controller.asset_host = cdn_url
|
|
|
|
ActionController::Base.asset_host = cdn_url
|
|
|
|
|
|
|
|
before_next_spec do
|
|
|
|
Rails.configuration.action_controller.asset_host = nil
|
|
|
|
ActionController::Base.asset_host = nil
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
def freeze_time(now = Time.now)
|
2019-03-28 02:28:01 -04:00
|
|
|
time = now
|
|
|
|
datetime = now
|
|
|
|
|
|
|
|
if Time === now
|
|
|
|
datetime = now.to_datetime
|
|
|
|
elsif DateTime === now
|
|
|
|
time = now.to_time
|
|
|
|
else
|
|
|
|
datetime = DateTime.parse(now.to_s)
|
|
|
|
time = Time.parse(now.to_s)
|
|
|
|
end
|
2017-07-24 09:17:42 -04:00
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
if block_given?
|
|
|
|
raise "nested freeze time not supported" if TrackTimeStub.stubbed
|
2013-02-05 14:16:51 -05:00
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
DateTime.stubs(:now).returns(datetime)
|
|
|
|
Time.stubs(:now).returns(time)
|
|
|
|
Date.stubs(:today).returns(datetime.to_date)
|
|
|
|
TrackTimeStub.stubs(:stubbed).returns(true)
|
|
|
|
|
|
|
|
if block_given?
|
|
|
|
begin
|
|
|
|
yield
|
|
|
|
ensure
|
|
|
|
unfreeze_time
|
|
|
|
end
|
2020-03-10 17:13:17 -04:00
|
|
|
else
|
|
|
|
time
|
2014-07-14 11:34:23 -04:00
|
|
|
end
|
2013-02-05 14:16:51 -05:00
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
def unfreeze_time
|
|
|
|
DateTime.unstub(:now)
|
|
|
|
Time.unstub(:now)
|
|
|
|
Date.unstub(:today)
|
|
|
|
TrackTimeStub.unstub(:stubbed)
|
2013-05-16 01:03:03 -04:00
|
|
|
end
|
|
|
|
|
2017-08-09 17:50:59 -04:00
|
|
|
def file_from_fixtures(filename, directory = "images")
|
2020-05-18 19:09:36 -04:00
|
|
|
SpecSecureRandom.value ||= SecureRandom.hex
|
2022-01-05 12:45:08 -05:00
|
|
|
FileUtils.mkdir_p(file_from_fixtures_tmp_folder) unless Dir.exist?(file_from_fixtures_tmp_folder)
|
2020-05-18 19:09:36 -04:00
|
|
|
tmp_file_path = File.join(file_from_fixtures_tmp_folder, SecureRandom.hex << filename)
|
|
|
|
FileUtils.cp("#{Rails.root}/spec/fixtures/#{directory}/#{filename}", tmp_file_path)
|
|
|
|
File.new(tmp_file_path)
|
|
|
|
end
|
|
|
|
|
|
|
|
def file_from_fixtures_tmp_folder
|
|
|
|
File.join(Dir.tmpdir, "rspec_#{Process.pid}_#{SpecSecureRandom.value}")
|
2017-08-09 17:50:59 -04:00
|
|
|
end
|
2018-10-08 03:47:38 -04:00
|
|
|
|
|
|
|
def has_trigger?(trigger_name)
|
|
|
|
DB.exec(<<~SQL) != 0
|
|
|
|
SELECT 1
|
|
|
|
FROM INFORMATION_SCHEMA.TRIGGERS
|
|
|
|
WHERE trigger_name = '#{trigger_name}'
|
|
|
|
SQL
|
|
|
|
end
|
2018-11-19 08:50:00 -05:00
|
|
|
|
|
|
|
def silence_stdout
|
|
|
|
STDOUT.stubs(:write)
|
|
|
|
yield
|
|
|
|
ensure
|
|
|
|
STDOUT.unstub(:write)
|
|
|
|
end
|
2020-04-07 22:42:28 -04:00
|
|
|
|
2022-05-04 21:50:43 -04:00
|
|
|
def track_log_messages
|
2020-04-07 22:42:28 -04:00
|
|
|
old_logger = Rails.logger
|
2022-05-04 21:50:43 -04:00
|
|
|
logger = Rails.logger = FakeLogger.new
|
|
|
|
yield logger
|
|
|
|
logger
|
2020-04-07 22:42:28 -04:00
|
|
|
ensure
|
|
|
|
Rails.logger = old_logger
|
|
|
|
end
|
2020-05-18 19:09:36 -04:00
|
|
|
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
# this takes a string and returns a copy where 2 different
|
|
|
|
# characters are swapped.
|
|
|
|
# e.g.
|
|
|
|
# swap_2_different_characters("abc") => "bac"
|
|
|
|
# swap_2_different_characters("aac") => "caa"
|
|
|
|
def swap_2_different_characters(str)
|
|
|
|
swap1 = 0
|
|
|
|
swap2 = str.split("").find_index { |c| c != str[swap1] }
|
|
|
|
# if the string is made up of 1 character
|
|
|
|
return str if !swap2
|
|
|
|
str = str.dup
|
|
|
|
str[swap1], str[swap2] = str[swap2], str[swap1]
|
|
|
|
str
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_request_env(path: nil)
|
|
|
|
env = Rails.application.env_config.dup
|
|
|
|
env.merge!(Rack::MockRequest.env_for(path)) if path
|
|
|
|
env
|
|
|
|
end
|
|
|
|
|
2022-05-19 10:58:31 -04:00
|
|
|
def create_auth_cookie(token:, user_id: nil, trust_level: nil, issued_at: Time.current)
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
data = { token: token, user_id: user_id, trust_level: trust_level, issued_at: issued_at.to_i }
|
2022-05-19 10:58:31 -04:00
|
|
|
jar = ActionDispatch::Cookies::CookieJar.build(ActionDispatch::TestRequest.create, {})
|
|
|
|
jar.encrypted[:_t] = { value: data }
|
|
|
|
CGI.escape(jar[:_t])
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def decrypt_auth_cookie(cookie)
|
2022-05-19 10:58:31 -04:00
|
|
|
ActionDispatch::Cookies::CookieJar.build(
|
|
|
|
ActionDispatch::TestRequest.create,
|
|
|
|
{ _t: cookie },
|
|
|
|
).encrypted[
|
|
|
|
:_t
|
|
|
|
].with_indifferent_access
|
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).
This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).
For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.
The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.
Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.
Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.
Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.
Internal ticket number: t54739.
2021-11-17 15:27:30 -05:00
|
|
|
end
|
|
|
|
|
2020-05-18 19:09:36 -04:00
|
|
|
class SpecSecureRandom
|
|
|
|
class << self
|
|
|
|
attr_accessor :value
|
|
|
|
end
|
|
|
|
end
|