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 "
2024-04-28 20:34:28 -04:00
require " pry-stack_explorer "
2017-08-09 17:50:59 -04:00
require " fabrication "
require " mocha/api "
require " certified "
require " webmock/rspec "
2023-08-22 21:18:33 -04:00
require " minio_runner "
2017-08-09 17:50:59 -04:00
2018-05-21 03:01:30 -04:00
class RspecErrorTracker
2023-12-20 02:17:12 -05:00
def self . exceptions
@exceptions || = { }
2018-05-21 03:01:30 -04:00
end
2023-12-20 02:17:12 -05:00
def self . clear_exceptions
@exceptions & . clear
end
def self . report_exception ( path , exception )
exceptions [ path ] = exception
2018-05-21 03:01:30 -04:00
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
2023-12-20 02:17:12 -05:00
RspecErrorTracker . report_exception ( env [ " PATH_INFO " ] , e )
2018-05-21 03:01:30 -04:00
raise e
end
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 "
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 " 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 }
2023-07-28 07:53:46 -04:00
Dir [ Rails . root . join ( " spec/requests/examples/*.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
DEV: make sure we don't load all data into memory when exporting chat messages (#22276)
This commit makes sure we don't load all data into memory when doing CSV exports.
The most important change here made to the recently introduced export of chat
messages (3ea31f4). We were loading all data into memory in the first version, with
this commit it's not the case anymore.
Speaking of old exports. Some of them already use find_each, and it worked as
expected, without loading all data into memory. And it will proceed working as
expected after this commit.
In general, I made sure this change didn't break other CSV exports, first manually, and
then by writing system specs for them. Sadly, I haven't managed yet to make those
specs stable, they work fine locally, but flaky in GitHub actions, so I've disabled them
for now.
I'll be making more changes to the CSV exports code soon, those system specs will be
very helpful. I'll be running them locally, and I hope I'll manage to make them stable
while doing that work.
2023-07-12 10:52:18 -04:00
Dir [ Rails . root . join ( " spec/system/helpers/**/*.rb " ) ] . each { | f | require f }
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
2023-12-20 02:17:12 -05:00
RspecErrorTracker . clear_exceptions
2019-05-06 23:12:20 -04:00
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
2023-07-28 07:53:44 -04:00
Middleware :: AnonymousCache . disable_anon_cache
2024-02-15 18:01:36 -05:00
BlockRequestsMiddleware . allow_requests!
DEV: Do not process requests initiated by browser in a different example (#25809)
Why this change?
We noticed that running `LOAD_PLUGINS=1 rspec --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` locally
results in the system tests randomly failing. When we inspected the
request logs closely, we noticed that a `/presence/get` request from a
previous rspec example was being processed when a new rspec example is
already being run. We know it was from the previous rspec example
because inspecting the auth token showed the request using the auth
token of a user from the previous example. However, when a request using
an auth token from a previous example is used it ends up logging out the
same user on the server side because the user id in the cookie is the same
due to the use of `fab!`.
I did some research and there is apparently no way to wait until all
inflight requests by the browser has completed through capybara or
selenium. Therefore, we will add an identifier by attaching a cookie to all non-xhr requests so that
xhr requests which are triggered subsequently will contain the cookie in the request.
In the `BlockRequestsMiddleware` middleware, we will then reject any
requests when the value of the identifier in the cookie does not match the current rspec's example
location.
To see the problem locally, change `Auth::DefaultCurrentUserProvider.find_v1_auth_cookie` to the following:
```
def self.find_v1_auth_cookie(env)
return env[DECRYPTED_AUTH_COOKIE] if env.key?(DECRYPTED_AUTH_COOKIE)
env[DECRYPTED_AUTH_COOKIE] = begin
request = ActionDispatch::Request.new(env)
cookie = request.cookies[TOKEN_COOKIE]
# don't even initialize a cookie jar if we don't have a cookie at all
if cookie&.valid_encoding? && cookie.present?
puts "#{env["REQUEST_PATH"]} #{request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access}"
request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access
end
end
end
```
After which run the following command: `LOAD_PLUGINS=1 rspec --format documentation --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb`
It takes a few tries but the last spec should fail and you should see something like this:
```
assets/chunk.c16f6ba8b6824baa47ac.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/assets/chunk.050148142e1d2dc992dd.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/chat/api/channels/527/messages {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/uploads/default/test_0/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_512x512.png {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
redirects to existing chat channel
redirects to chat channel if recipients param is missing (PENDING: Temporarily skipped with xit)
with multiple users
/favicon.ico {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736}
/chat/new-message {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736}
/presence/get {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
```
Note how the `/presence/get` request is using a token from the previous example.
Co-authored-by: David Taylor <david@taylorhq.com>
2024-02-22 06:41:10 -05:00
BlockRequestsMiddleware . current_example_location = nil
2019-05-06 23:12:20 -04:00
end
end
2024-01-16 22:00:32 -05:00
if ENV [ " PREFABRICATION " ] == " 0 "
module Prefabrication
2023-11-09 17:47:59 -05:00
def fab! ( name , ** opts , & blk )
blk || = proc { Fabricate ( name ) }
2019-05-06 23:12:20 -04:00
let! ( name , & blk )
end
2024-01-16 22:00:32 -05:00
end
else
require " test_prof/recipes/rspec/let_it_be "
require " test_prof/before_all/adapters/active_record "
TestProf :: BeforeAll . configure do | config |
config . after ( :begin ) do
DB . test_transaction = ActiveRecord :: Base . connection . current_transaction
TestSetup . test_setup
end
end
module Prefabrication
2023-11-09 17:47:59 -05:00
def fab! ( name , ** opts , & blk )
blk || = proc { Fabricate ( name ) }
let_it_be ( name , refind : true , ** opts , & blk )
end
2019-05-06 23:12:20 -04:00
end
end
2023-12-08 15:14:41 -05:00
PER_SPEC_TIMEOUT_SECONDS = 45
2023-12-07 17:46:20 -05:00
BROWSER_READ_TIMEOUT = 30
2023-05-19 06:08:48 -04:00
2024-07-31 04:12:54 -04:00
# To avoid erasing `any_instance` from Mocha
require " rspec/mocks/syntax "
RSpec :: Mocks :: Syntax . singleton_class . define_method ( :enable_should ) { | * | nil }
RSpec :: Mocks :: Syntax . singleton_class . define_method ( :disable_should ) { | * | nil }
RSpec :: Mocks :: ArgumentMatchers . remove_method ( :hash_including ) # We’ re currently relying on the version from Webmock
2017-08-09 17:50:59 -04:00
RSpec . configure do | config |
2024-07-31 04:12:54 -04:00
config . expect_with :rspec do | c |
c . syntax = :expect
end
2017-08-09 17:50:59 -04:00
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
2024-01-16 22:00:32 -05:00
config . extend Prefabrication
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
2023-08-18 08:39:10 -04:00
config . include DiscourseWebauthnIntegrationHelpers
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
2024-08-16 00:51:57 -04:00
config . include BackupsHelpers
2021-05-26 05:41:35 -04:00
config . include OneboxHelpers
2021-10-19 07:42:29 -04:00
config . include FastImageHelpers
2024-04-12 07:14:19 -04:00
config . include ServiceMatchers
2024-05-24 10:15:53 -04:00
config . include I18nHelpers
2024-04-12 07:14:19 -04:00
2017-08-09 17:50:59 -04:00
config . order = " random "
config . infer_spec_type_from_file_location!
2013-02-05 14:16:51 -05:00
2024-07-31 04:12:54 -04:00
config . mock_with :rspec do | mocks |
mocks . verify_partial_doubles = true
mocks . verify_doubled_constant_names = true
mocks . syntax = :expect
end
config . mock_with MultiMock :: Adapter . for ( :mocha , :rspec )
config . include Mocha :: API
2023-05-12 12:22:15 -04:00
if ENV [ " GITHUB_ACTIONS " ]
# Enable color output in GitHub Actions
# This eventually will be `config.color_mode = :on` in RSpec 4?
config . tty = true
config . color = true
end
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
2024-07-31 00:08:37 -04:00
# Shows more than one line of backtrace in case of an error or spec failure.
config . full_cause_backtrace = false
# Sometimes the backtrace is quite big for failing specs, this will
# remove rspec/gem paths from the backtrace so it's easier to see the
# actual application code that caused the failure.
2024-12-03 18:54:11 -05:00
#
# This behaviour is enabled by default, to include gems in
# the backtrace set DISCOURSE_INCLUDE_GEMS_IN_RSPEC_BACKTRACE=1
if ENV [ " DISCOURSE_INCLUDE_GEMS_IN_RSPEC_BACKTRACE " ] != " 1 "
2024-07-31 00:08:37 -04:00
config . backtrace_exclusion_patterns = [
%r{ /lib \ d*/ruby/ } ,
%r{ bin/ } ,
/ gems / ,
%r{ spec/spec_helper \ .rb } ,
%r{ spec/rails_helper \ .rb } ,
%r{ lib/rspec/(core|expectations|matchers|mocks) } ,
]
end
2024-02-06 05:56:49 -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
2024-06-20 04:33:01 -04:00
ActiveRecord :: Migration . check_all_pending!
2019-12-13 07:50:18 -05:00
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
2024-11-19 23:17:36 -05:00
Discourse :: Application . load_tasks
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
2023-08-22 21:18:33 -04:00
# Used for S3 system specs, see also setup_s3_system_test.
MinioRunner . config do | minio_runner_config |
minio_runner_config . minio_domain = ENV [ " MINIO_RUNNER_MINIO_DOMAIN " ] || " minio.local "
minio_runner_config . buckets =
(
if ENV [ " MINIO_RUNNER_BUCKETS " ]
ENV [ " MINIO_RUNNER_BUCKETS " ] . split ( " , " )
else
[ " discoursetest " ]
end
)
minio_runner_config . public_buckets =
(
if ENV [ " MINIO_RUNNER_PUBLIC_BUCKETS " ]
ENV [ " MINIO_RUNNER_PUBLIC_BUCKETS " ] . split ( " , " )
else
[ " discoursetest " ]
end
)
2024-10-16 05:40:58 -04:00
test_i = ENV [ " TEST_ENV_NUMBER " ] . to_i
data_dir = " #{ Rails . root } /tmp/test_data_ #{ test_i } /minio "
FileUtils . rm_rf ( data_dir )
FileUtils . mkdir_p ( data_dir )
minio_runner_config . minio_data_directory = data_dir
minio_runner_config . minio_port = 9_000 + 2 * test_i
minio_runner_config . minio_console_port = 9_001 + 2 * test_i
2023-08-22 21:18:33 -04:00
end
WebMock . disable_net_connect! (
allow_localhost : true ,
allow : [
* MinioRunner . config . minio_urls ,
URI ( MinioRunner :: MinioBinary . platform_binary_url ) . host ,
2023-09-07 23:17:08 -04:00
ENV [ " CAPYBARA_REMOTE_DRIVER_URL " ] ,
] . compact ,
2023-08-22 21:18:33 -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
2023-05-12 08:00:04 -04:00
if ENV [ " CAPYBARA_DEFAULT_MAX_WAIT_TIME " ] . present?
Capybara . default_max_wait_time = ENV [ " CAPYBARA_DEFAULT_MAX_WAIT_TIME " ] . to_i
2023-12-17 22:51:59 -05:00
else
Capybara . default_max_wait_time = 4
2023-01-04 19:50:35 -05:00
end
2023-01-02 09:17:21 -05:00
Capybara . threadsafe = true
2023-05-30 00:45:24 -04:00
Capybara . disable_animation = true
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 |
2024-05-27 23:32:22 -04:00
capybara_config . server_host = ENV [ " CAPYBARA_SERVER_HOST " ] . presence || " localhost "
2023-09-14 23:46:03 -04:00
capybara_config . server_port =
( ENV [ " CAPYBARA_SERVER_PORT " ] . presence || " 31_337 " ) . to_i + 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-08-08 05:16:09 -04:00
module CapybaraTimeoutExtension
class CapybaraTimedOut < StandardError
2023-08-09 06:56:09 -04:00
attr_reader :cause
def initialize ( wait_time , cause )
@cause = cause
super " This spec passed, but capybara waited for the full wait duration ( #{ wait_time } s) at least once. " +
2023-08-08 05:16:09 -04:00
" This will slow down the test suite. " +
" Beware of negating the result of selenium's RSpec matchers. "
end
end
def synchronize ( seconds = nil , errors : nil )
return super if session . synchronized # Nested synchronize. We only want our logic on the outermost call.
begin
super
rescue StandardError = > e
seconds = session_options . default_max_wait_time if [ nil , true ] . include? seconds
if catch_error? ( e , errors ) && seconds != 0
2023-08-09 06:56:09 -04:00
# This error will only have been raised if the timer expired
timeout_error = CapybaraTimedOut . new ( seconds , e )
if RSpec . current_example
# Store timeout for later, we'll only raise it if the test otherwise passes
RSpec . current_example . metadata [ :_capybara_timeout_exception ] || = timeout_error
raise # re-raise original error
else
# Outside an example... maybe a `before(:all)` hook?
raise timeout_error
end
2023-08-08 05:16:09 -04:00
else
raise
end
end
end
end
Capybara :: Node :: Base . prepend ( CapybaraTimeoutExtension )
2023-08-09 06:56:09 -04:00
config . after ( :each , type : :system ) do | example |
# If test passed, but we had a capybara finder timeout, raise it now
if example . exception . nil? &&
2023-12-06 16:25:26 -05:00
( capybara_timeout_error = example . metadata [ :_capybara_timeout_exception ] )
raise capybara_timeout_error
2023-08-09 06:56:09 -04:00
end
end
2023-05-28 08:16:38 -04:00
# possible values: OFF, SEVERE, WARNING, INFO, DEBUG, ALL
2023-12-13 11:04:25 -05:00
browser_log_level = ENV [ " SELENIUM_BROWSER_LOG_LEVEL " ] || " WARNING "
2023-05-28 08:16:38 -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
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 |
2023-05-28 08:16:38 -04:00
apply_base_chrome_options ( options )
2024-08-01 09:49:07 -04:00
options . add_argument ( " --disable-search-engine-choice-screen " )
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
options . add_argument ( " --window-size=1400,1400 " )
DEV: make sure we don't load all data into memory when exporting chat messages (#22276)
This commit makes sure we don't load all data into memory when doing CSV exports.
The most important change here made to the recently introduced export of chat
messages (3ea31f4). We were loading all data into memory in the first version, with
this commit it's not the case anymore.
Speaking of old exports. Some of them already use find_each, and it worked as
expected, without loading all data into memory. And it will proceed working as
expected after this commit.
In general, I made sure this change didn't break other CSV exports, first manually, and
then by writing system specs for them. Sadly, I haven't managed yet to make those
specs stable, they work fine locally, but flaky in GitHub actions, so I've disabled them
for now.
I'll be making more changes to the CSV exports code soon, those system specs will be
very helpful. I'll be running them locally, and I hope I'll manage to make them stable
while doing that work.
2023-07-12 10:52:18 -04:00
options . add_preference ( " download.default_directory " , Downloads :: FOLDER )
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-12-12 06:29:23 -05:00
driver_options = { browser : :chrome , timeout : BROWSER_READ_TIMEOUT }
2023-09-07 02:07:17 -04:00
if ENV [ " CAPYBARA_REMOTE_DRIVER_URL " ] . present?
driver_options [ :browser ] = :remote
driver_options [ :url ] = ENV [ " CAPYBARA_REMOTE_DRIVER_URL " ]
end
desktop_driver_options = driver_options . merge ( 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
Capybara . register_driver :selenium_chrome do | app |
2023-09-07 02:07:17 -04:00
Capybara :: Selenium :: Driver . new ( app , ** desktop_driver_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 |
2023-05-26 05:02:56 -04:00
chrome_browser_options . add_argument ( " --headless=new " )
2023-09-07 02:07:17 -04:00
Capybara :: Selenium :: Driver . new ( app , ** desktop_driver_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
2023-05-28 08:16:38 -04:00
. new ( logging_prefs : { " browser " = > browser_log_level , " driver " = > " ALL " } )
2022-12-11 17:12:33 -05:00
. tap do | options |
2024-08-01 09:49:07 -04:00
options . add_argument ( " --disable-search-engine-choice-screen " )
2022-12-11 17:12:33 -05:00
options . add_emulation ( device_name : " iPhone 12 Pro " )
2023-08-16 16:07:03 -04:00
options . add_argument (
'--user-agent="--user-agent="Mozilla/5.0 (iPhone; CPU iPhone OS 14_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/36.0 Mobile/15E148 Safari/605.1.15"' ,
)
2023-05-28 08:16:38 -04:00
apply_base_chrome_options ( options )
2022-12-11 17:12:33 -05:00
end
2023-09-07 02:07:17 -04:00
mobile_driver_options = driver_options . merge ( options : mobile_chrome_browser_options )
2022-12-11 17:12:33 -05:00
Capybara . register_driver :selenium_mobile_chrome do | app |
2023-09-07 02:07:17 -04:00
Capybara :: Selenium :: Driver . new ( app , ** mobile_driver_options )
2022-12-11 17:12:33 -05:00
end
Capybara . register_driver :selenium_mobile_chrome_headless do | app |
2023-05-26 05:02:56 -04:00
mobile_chrome_browser_options . add_argument ( " --headless=new " )
2023-09-07 02:07:17 -04:00
Capybara :: Selenium :: Driver . new ( app , ** mobile_driver_options )
2022-12-11 17:12:33 -05:00
end
2024-11-19 14:22:02 -05:00
[
[ PostAction , :post_action_type_id ] ,
[ Reviewable , :target_id ] ,
[ ReviewableHistory , :reviewable_id ] ,
[ ReviewableScore , :reviewable_id ] ,
[ ReviewableScore , :reviewable_score_type ] ,
[ SidebarSectionLink , :linkable_id ] ,
[ SidebarSectionLink , :sidebar_section_id ] ,
[ User , :last_seen_reviewable_id ] ,
[ User , :required_fields_version ] ,
] . each do | model , column |
DB . exec ( " ALTER TABLE #{ model . table_name } ALTER #{ column } TYPE bigint " )
model . reset_column_information
2021-12-07 13:26:35 -05:00
end
2023-07-16 20:14:17 -04:00
2024-10-14 19:44:27 -04:00
# Sets sequence's value to be greater than the max value that an INT column can hold. This is done to prevent
# type mistmatches for foreign keys that references a column of type BIGINT. We set the value to 10_000_000_000
# instead of 2**31-1 so that the values are easier to read.
2024-10-10 12:28:45 -04:00
DB
. query ( " SELECT sequence_name FROM information_schema.sequences WHERE data_type = 'bigint' " )
2024-10-14 19:44:27 -04:00
. each { | row | DB . exec " SELECT setval(' #{ row . sequence_name } ', '10000000000') " }
2024-10-10 12:28:45 -04:00
2023-07-16 20:14:17 -04:00
# Prevents 500 errors for site setting URLs pointing to test.localhost in system specs.
SiteIconManager . clear_cache!
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
2020-05-18 19:09:36 -04:00
config . after ( :suite ) do
2023-06-04 20:06:00 -04:00
FileUtils . remove_dir ( concurrency_safe_tmp_dir , true ) if SpecSecureRandom . value
DEV: make sure we don't load all data into memory when exporting chat messages (#22276)
This commit makes sure we don't load all data into memory when doing CSV exports.
The most important change here made to the recently introduced export of chat
messages (3ea31f4). We were loading all data into memory in the first version, with
this commit it's not the case anymore.
Speaking of old exports. Some of them already use find_each, and it worked as
expected, without loading all data into memory. And it will proceed working as
expected after this commit.
In general, I made sure this change didn't break other CSV exports, first manually, and
then by writing system specs for them. Sadly, I haven't managed yet to make those
specs stable, they work fine locally, but flaky in GitHub actions, so I've disabled them
for now.
I'll be making more changes to the CSV exports code soon, those system specs will be
very helpful. I'll be running them locally, and I hope I'll manage to make them stable
while doing that work.
2023-07-12 10:52:18 -04:00
Downloads . clear
2023-08-22 21:18:33 -04:00
MinioRunner . stop
2020-05-18 19:09:36 -04:00
end
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
2023-05-19 06:08:48 -04:00
if ENV [ " CI " ]
2023-05-30 13:14:54 -04:00
class SpecTimeoutError < StandardError
end
2024-01-22 17:55:49 -05:00
mutex = Mutex . new
condition_variable = ConditionVariable . new
test_running = false
is_waiting = false
backtrace_logger =
Thread . new do
loop do
mutex . synchronize do
is_waiting = true
condition_variable . wait ( mutex )
is_waiting = false
end
sleep PER_SPEC_TIMEOUT_SECONDS - 1
if mutex . synchronize { test_running }
puts " ::group::[ #{ Process . pid } ] Threads backtraces 1 second before timeout "
Thread . list . each do | thread |
puts " \n "
thread . backtrace . each { | line | puts line }
puts " \n "
end
puts " ::endgroup:: "
end
rescue StandardError = > e
puts " Error in backtrace logger: #{ e } "
end
end
2023-05-19 06:08:48 -04:00
config . around do | example |
Timeout . timeout (
PER_SPEC_TIMEOUT_SECONDS ,
2023-05-30 13:14:54 -04:00
SpecTimeoutError ,
2023-05-19 06:08:48 -04:00
" Spec timed out after #{ PER_SPEC_TIMEOUT_SECONDS } seconds " ,
2023-05-30 13:14:54 -04:00
) do
2024-01-22 17:55:49 -05:00
mutex . synchronize do
test_running = true
condition_variable . signal
end
2023-05-30 13:14:54 -04:00
example . run
rescue SpecTimeoutError
2024-01-22 17:55:49 -05:00
ensure
mutex . synchronize { test_running = false }
backtrace_logger . wakeup
sleep 0 . 01 while ! mutex . synchronize { is_waiting }
2023-05-30 13:14:54 -04:00
end
2023-05-19 06:08:48 -04:00
end
2024-06-02 22:26:02 -04:00
2024-06-10 01:14:50 -04:00
# This is a monkey patch for the `Capybara.using_session` method in `capybara`. For some
2024-06-04 19:54:15 -04:00
# unknown reasons on Github Actions, we are seeing system tests failing intermittently with the error
2024-06-10 01:14:50 -04:00
# `Socket::ResolutionError: getaddrinfo: Temporary failure in name resolution` when the app tries to resolve
2024-06-11 02:49:01 -04:00
# `localhost` from within a `Capybara#using_session` block.
2024-06-04 19:54:15 -04:00
#
# Too much time has been spent trying to debug this issue and the root cause is still unknown so we are just dropping
2024-06-11 02:49:01 -04:00
# this workaround for now where we will retry the block once before raising the error.
#
# Potentially related: https://bugs.ruby-lang.org/issues/20172
2024-06-10 01:14:50 -04:00
module Capybara
class << self
def using_session_with_localhost_resolution ( name , & block )
2024-06-11 02:49:01 -04:00
attempts = 0
self . _using_session ( name , & block )
rescue Socket :: ResolutionError
puts " Socket::ResolutionError error encountered... Current thread count: #{ Thread . list . size } "
2024-06-11 04:05:38 -04:00
attempts += 1
2024-06-11 02:49:01 -04:00
attempts < = 1 ? retry : raise
2024-06-04 19:54:15 -04:00
end
2024-06-02 22:26:02 -04:00
end
end
2024-06-04 19:54:15 -04:00
2024-06-10 01:14:50 -04:00
Capybara . singleton_class . class_eval do
alias_method :_using_session , :using_session
alias_method :using_session , :using_session_with_localhost_resolution
2024-06-04 19:54:15 -04:00
end
2023-05-19 06:08:48 -04:00
end
2023-05-29 21:52:46 -04:00
if ENV [ " DISCOURSE_RSPEC_PROFILE_EACH_EXAMPLE " ]
config . around :each do | example |
measurement = Benchmark . measure { example . run }
RSpec . current_example . metadata [ :run_duration_ms ] = ( measurement . real * 1000 ) . round ( 2 )
end
end
2023-12-27 01:40:00 -05:00
if ENV [ " GITHUB_ACTIONS " ]
config . around :each , capture_log : true do | example |
original_logger = ActiveRecord :: Base . logger
io = StringIO . new
io_logger = Logger . new ( io )
io_logger . level = Logger :: DEBUG
ActiveRecord :: Base . logger = io_logger
example . run
RSpec . current_example . metadata [ :active_record_debug_logs ] = io . string
ensure
ActiveRecord :: Base . logger = original_logger
end
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
2023-07-12 10:49:28 -04:00
TestSetup . test_setup
2020-12-07 19:03:31 -05:00
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 ( :each , type : % i [ request multisite system ] ) { host! " test.localhost " }
2023-12-21 19:40:02 -05:00
system_tests_initialized = 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
config . before ( :each , type : :system ) do | example |
2023-12-21 19:40:02 -05:00
if ! system_tests_initialized
# Use a file system lock to get `selenium-manager` to download the `chromedriver` binary that is required for
# system tests to support running system tests in multiple processes. If we don't download the `chromedriver` binary
# before running system tests in multiple processes, each process will end up calling the `selenium-manager` binary
# to download the `chromedriver` binary at the same time but the problem is that the binary is being downloaded to
# the same location and this can interfere with the running tests in another process.
#
# The long term fix here is to get `selenium-manager` to download the `chromedriver` binary to a unique path for each
# process but the `--cache-path` option for `selenium-manager` is currently not supported in `selenium-webdriver`.
2024-02-01 22:04:37 -05:00
File . open ( " #{ Rails . root } /tmp/chrome_driver_flock " , File :: RDWR | File :: CREAT , 0644 ) do | file |
file . flock ( File :: LOCK_EX )
if ! File . directory? ( File . expand_path ( " ~/.cache/selenium " ) )
2023-12-21 19:40:02 -05:00
` #{ Selenium :: WebDriver :: SeleniumManager . send ( :binary ) } --browser chrome `
end
end
# On Rails 7, we have seen instances of deadlocks between the lock in [ActiveRecord::ConnectionAdapaters::AbstractAdapter](https://github.com/rails/rails/blob/9d1673853f13cd6f756315ac333b20d512db4d58/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L86)
# and the lock in [ActiveRecord::ModelSchema](https://github.com/rails/rails/blob/9d1673853f13cd6f756315ac333b20d512db4d58/activerecord/lib/active_record/model_schema.rb#L550).
# To work around this problem, we are going to preload all the model schemas before running any system tests so that
# the lock in ActiveRecord::ModelSchema is not acquired at runtime. This is a temporary workaround while we report
# the issue to the Rails.
ActiveRecord :: Base . connection . data_sources . map do | table |
ActiveRecord :: Base . connection . schema_cache . add ( table )
end
system_tests_initialized = true
end
2023-06-06 21:26:58 -04:00
driver = [ :selenium ]
driver << :mobile if example . metadata [ :mobile ]
2024-03-19 02:47:14 -04:00
driver << :chrome
2023-06-06 21:26:58 -04:00
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
setup_system_test
DEV: Do not process requests initiated by browser in a different example (#25809)
Why this change?
We noticed that running `LOAD_PLUGINS=1 rspec --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb` locally
results in the system tests randomly failing. When we inspected the
request logs closely, we noticed that a `/presence/get` request from a
previous rspec example was being processed when a new rspec example is
already being run. We know it was from the previous rspec example
because inspecting the auth token showed the request using the auth
token of a user from the previous example. However, when a request using
an auth token from a previous example is used it ends up logging out the
same user on the server side because the user id in the cookie is the same
due to the use of `fab!`.
I did some research and there is apparently no way to wait until all
inflight requests by the browser has completed through capybara or
selenium. Therefore, we will add an identifier by attaching a cookie to all non-xhr requests so that
xhr requests which are triggered subsequently will contain the cookie in the request.
In the `BlockRequestsMiddleware` middleware, we will then reject any
requests when the value of the identifier in the cookie does not match the current rspec's example
location.
To see the problem locally, change `Auth::DefaultCurrentUserProvider.find_v1_auth_cookie` to the following:
```
def self.find_v1_auth_cookie(env)
return env[DECRYPTED_AUTH_COOKIE] if env.key?(DECRYPTED_AUTH_COOKIE)
env[DECRYPTED_AUTH_COOKIE] = begin
request = ActionDispatch::Request.new(env)
cookie = request.cookies[TOKEN_COOKIE]
# don't even initialize a cookie jar if we don't have a cookie at all
if cookie&.valid_encoding? && cookie.present?
puts "#{env["REQUEST_PATH"]} #{request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access}"
request.cookie_jar.encrypted[TOKEN_COOKIE]&.with_indifferent_access
end
end
end
```
After which run the following command: `LOAD_PLUGINS=1 rspec --format documentation --seed=38855 plugins/chat/spec/system/chat_new_message_spec.rb`
It takes a few tries but the last spec should fail and you should see something like this:
```
assets/chunk.c16f6ba8b6824baa47ac.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/assets/chunk.050148142e1d2dc992dd.d41d8cd9.js {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/chat/api/channels/527/messages {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
/uploads/default/test_0/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_512x512.png {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
redirects to existing chat channel
redirects to chat channel if recipients param is missing (PENDING: Temporarily skipped with xit)
with multiple users
/favicon.ico {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736}
/chat/new-message {"token"=>"9a75c114c4d3401509a23d240f0a46d4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591736}
/presence/get {"token"=>"37d995a4b65395d3b343ec70fff915b4", "user_id"=>3382, "username"=>"bruce0", "trust_level"=>1, "issued_at"=>1708591735}
```
Note how the `/presence/get` request is using a token from the previous example.
Co-authored-by: David Taylor <david@taylorhq.com>
2024-02-22 06:41:10 -05:00
BlockRequestsMiddleware . current_example_location = example . location
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
2024-10-14 03:24:29 -04:00
config . after :each do | example |
2024-12-03 18:54:11 -05:00
# This behaviour is enabled by default, to include gems in
# the backtrace set DISCOURSE_INCLUDE_GEMS_IN_RSPEC_BACKTRACE=1
if example . exception && ENV [ " DISCOURSE_INCLUDE_GEMS_IN_RSPEC_BACKTRACE " ] != " 1 "
lines = ( RSpec . current_example . metadata [ :extra_failure_lines ] || = + " " )
lines << " Warning: DISCOURSE_INCLUDE_GEMS_IN_RSPEC_BACKTRACE has not been enabled, gem backtrace will be excluded from the output \n "
end
2024-10-14 03:24:29 -04:00
if example . exception && RspecErrorTracker . exceptions . present?
lines = ( RSpec . current_example . metadata [ :extra_failure_lines ] || = + " " )
2024-12-03 18:54:11 -05:00
lines << " \n "
2024-10-14 03:24:29 -04:00
lines << " ~~~~~~~ SERVER EXCEPTIONS ~~~~~~~ "
2024-12-03 18:54:11 -05:00
lines << " \n "
2024-10-14 03:24:29 -04:00
RspecErrorTracker . exceptions . each_with_index do | ( path , ex ) , index |
lines << " \n "
2024-12-03 18:54:11 -05:00
lines << " Error encountered while processing #{ path } . \n "
lines << " #{ ex . class } : #{ ex . message } \n "
framework_lines_excluded = 0
2024-10-14 03:24:29 -04:00
ex . backtrace . each_with_index do | line , backtrace_index |
2024-12-03 18:54:11 -05:00
if ENV [ " DISCOURSE_INCLUDE_GEMS_IN_RSPEC_BACKTRACE " ] != " 1 "
if line . match? ( %r{ /gems/ } )
framework_lines_excluded += 1
next
else
if framework_lines_excluded . positive?
lines << " ...( #{ framework_lines_excluded } framework line(s) excluded) \n "
framework_lines_excluded = 0
end
end
2024-10-14 03:24:29 -04:00
end
lines << " #{ line } \n "
end
end
2024-12-03 18:54:11 -05:00
lines << " \n "
2024-10-14 03:24:29 -04:00
lines << " ~~~~~~~ END SERVER EXCEPTIONS ~~~~~~~ "
lines << " \n "
end
unfreeze_time
ActionMailer :: Base . deliveries . clear
Discourse . redis . flushdb
2024-11-14 21:19:10 -05:00
Scheduler :: Defer . do_all_work
2024-10-14 03:24:29 -04:00
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 , 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
2024-03-19 02:47:14 -04:00
js_logs = page . driver . browser . logs . get ( :browser )
2023-12-13 11:04:25 -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
# 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
2023-12-20 02:17:12 -05:00
lines << " ~~~~~~~ JS LOGS ~~~~~~~ "
if js_logs . empty?
lines << " (no logs) "
else
js_logs . each do | log |
# System specs are full of image load errors that are just noise, no need
# to log this.
if (
log . message . include? ( " Failed to load resource: net::ERR_CONNECTION_REFUSED " ) &&
( log . message . include? ( " uploads " ) || log . message . include? ( " images " ) )
) || log . message . include? ( " favicon.ico " )
next
2023-06-28 03:20:05 -04:00
end
2023-12-20 02:17:12 -05:00
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
end
2023-12-20 02:17:12 -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
2022-12-11 18:53:39 -05:00
2023-12-13 11:04:25 -05:00
js_logs . each do | log |
next if log . level != " WARNING "
deprecation_id = log . message [ / \ [deprecation id: ([^ \ ]]+) \ ] / , 1 ]
next if deprecation_id . nil?
deprecations = RSpec . current_example . metadata [ :js_deprecations ] || = { }
deprecations [ deprecation_id ] || = 0
deprecations [ deprecation_id ] += 1
end
2023-05-31 09:00:35 -04:00
page . execute_script ( " if (typeof MessageBus !== 'undefined') { MessageBus.stop(); } " )
2024-02-15 03:36:12 -05:00
# Block all incoming requests before resetting Capybara session which will wait for all requests to finish
BlockRequestsMiddleware . block_requests!
2024-02-15 01:00:30 -05:00
Capybara . reset_session!
2023-08-09 19:32:27 -04:00
MessageBus . backend_instance . reset! # Clears all existing backlog from memory backend
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
2024-06-20 04:33:01 -04:00
ActiveRecord :: Base . connection_handler . 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
2024-02-29 19:07:35 -05:00
# Time.now can cause flaky tests, especially in cases like
# leap days. This method freezes time at a "safe" specific
# time (the Discourse 1.1 release date), so it will not be
# affected by further temporal disruptions.
def freeze_time_safe
freeze_time ( DateTime . parse ( " 2014-08-26 12:00:00 " ) )
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
2024-03-26 02:17:51 -04:00
def file_from_fixtures ( filename , directory = " images " , root_path = " #{ Rails . root } /spec/fixtures " )
2023-06-04 20:06:00 -04:00
tmp_file_path = File . join ( concurrency_safe_tmp_dir , SecureRandom . hex << filename )
2024-03-26 02:17:51 -04:00
FileUtils . cp ( " #{ root_path } / #{ directory } / #{ filename } " , tmp_file_path )
2020-05-18 19:09:36 -04:00
File . new ( tmp_file_path )
end
2024-03-26 23:12:51 -04:00
def plugin_file_from_fixtures ( filename , directory = " images " )
# We [1] here instead of [0] because the first caller is the current method.
#
# /home/mb/repos/discourse-ai/spec/lib/modules/ai_bot/tools/discourse_meta_search_spec.rb:17:in `block (2 levels) in <main>'
first_non_gem_caller = caller_locations . select { | loc | ! loc . to_s . match? ( / gems / ) } [ 1 ] & . path
raise StandardError . new ( " Could not find caller for fixture #{ filename } " ) if ! first_non_gem_caller
# This is the full path of the plugin spec file that needs a fixture.
# realpath makes sure we follow symlinks.
#
# #<Pathname:/home/mb/repos/discourse-ai/spec/lib/modules/ai_bot/tools/discourse_meta_search_spec.rb>
plugin_caller_path = Pathname . new ( first_non_gem_caller ) . realpath
plugin_match =
Discourse . plugins . find do | plugin |
# realpath makes sure we follow symlinks
plugin_caller_path . to_s . starts_with? ( Pathname . new ( plugin . root_dir ) . realpath . to_s )
end
if ! plugin_match
raise StandardError . new (
" Could not find matching plugin for #{ plugin_caller_path } and fixture #{ filename } " ,
)
end
file_from_fixtures ( filename , directory , " #{ plugin_match . root_dir } /spec/fixtures " )
2024-03-26 02:17:51 -04:00
end
2023-09-01 13:22:58 -04:00
def file_from_contents ( contents , filename , directory = " images " )
tmp_file_path = File . join ( concurrency_safe_tmp_dir , SecureRandom . hex << filename )
File . write ( tmp_file_path , contents )
File . new ( tmp_file_path )
end
2023-06-04 20:06:00 -04:00
def plugin_from_fixtures ( plugin_name )
tmp_plugins_dir = File . join ( concurrency_safe_tmp_dir , " plugins " )
FileUtils . mkdir ( tmp_plugins_dir ) if ! Dir . exist? ( tmp_plugins_dir )
FileUtils . cp_r ( " #{ Rails . root } /spec/fixtures/plugins/ #{ plugin_name } " , tmp_plugins_dir )
plugin = Plugin :: Instance . new
plugin . path = File . join ( tmp_plugins_dir , plugin_name , " plugin.rb " )
plugin
end
def concurrency_safe_tmp_dir
SpecSecureRandom . value || = SecureRandom . hex
dir_path = File . join ( Dir . tmpdir , " rspec_ #{ Process . pid } _ #{ SpecSecureRandom . value } " )
FileUtils . mkdir_p ( dir_path ) unless Dir . exist? ( dir_path )
dir_path
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
2024-11-12 19:47:39 -05:00
logger = FakeLogger . new
Rails . logger . broadcast_to ( logger )
2022-05-04 21:50:43 -04:00
yield logger
logger
2020-04-07 22:42:28 -04:00
ensure
2024-11-12 19:47:39 -05:00
Rails . logger . stop_broadcasting_to ( logger )
2020-04-07 22:42:28 -04:00
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
2023-05-28 08:16:38 -04:00
def apply_base_chrome_options ( options )
# possible values: undocked, bottom, right, left
chrome_dev_tools = ENV [ " CHROME_DEV_TOOLS " ]
if chrome_dev_tools
options . add_argument ( " --auto-open-devtools-for-tabs " )
options . add_preference (
" devtools " ,
" preferences " = > {
" currentDockState " = > " \" #{ chrome_dev_tools } \" " ,
" panel-selectedTab " = > '"console"' ,
} ,
)
end
options . add_argument ( " --no-sandbox " )
options . add_argument ( " --disable-dev-shm-usage " )
options . add_argument ( " --mute-audio " )
2024-11-13 04:27:48 -05:00
options . add_argument ( " --remote-allow-origins=* " )
2023-07-18 20:09:34 -04:00
# A file that contains just a list of paths like so:
#
# /home/me/.config/google-chrome/Default/Extensions/bmdblncegkenkacieihfhpjfppoconhi/4.9.1_0
#
# These paths can be found for each individual extension via the
# chrome://extensions/ page.
if ENV [ " CHROME_LOAD_EXTENSIONS_MANIFEST " ] . present?
File
. readlines ( ENV [ " CHROME_LOAD_EXTENSIONS_MANIFEST " ] )
. each { | path | options . add_argument ( " --load-extension= #{ path } " ) }
end
if ENV [ " CHROME_DISABLE_FORCE_DEVICE_SCALE_FACTOR " ] . blank?
options . add_argument ( " --force-device-scale-factor=1 " )
end
2024-01-11 12:03:10 -05:00
end
2020-05-18 19:09:36 -04:00
class SpecSecureRandom
class << self
attr_accessor :value
end
end