New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEV: Minimal first pass of rails system test setup #16311
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Gods...was it ever difficult to figure out the correct host and port setup as well as driven_by for this thing...hoping it doesn't break a bunch of other tests.
spec/(?!system) is not a valid pattern for turbo_rspec
docker service now
…ourse/discourse into dev/experimental-rails-system-tests
Use it before system tests run
I will uncomment all the other test runs before merging this. |
martin-brennan
reviewed
Sep 1, 2022
* Simplify selenium launching using `webdrivers` gem This is the default way of handling system tests when spinning up a new Rails app via `rails new`. It means there is no need to manually launch Selenium. This commit also removes the docker container approach. Personally I think using the locally installed version of Chrome is fine - it's what we do for qunit tests, and it will be significantly faster than the dockerised version on non-linux machines. Also, the `selenium/standalone-chrome-debug` image appears to be abandoned - it hasn't been updated for more than a year. If we want to use this approach we should use a more up-to-date image like `selenium/standalone-chrome`. * Update GitHub actions config * Revert ChromeInstalledChecker changes This refactoring doesn't seem to be required any more - reverting to clean up the diff * Simplify host, port and WebMock configuration Now that we're using the `webdrivers` gem, the defaults work without too much tweaking * Remove SYSTEM_SPEC_RUN flag All the setup is now cheap, so we can do it unconditionally. This means that our system tests will work alongside regular rspec tests/tooling.
mcwumbly
approved these changes
Sep 28, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
This commit introduces rails system tests run with chromedriver, selenium,
and headless chrome to our testing toolbox.
We use the
webdrivers
gem andselenium-webdriver
which is whatthe 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 extraverbose 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 systemtests 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 avoidsurprises.
I have modified
bin/turbo_rspec
to excludespec/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 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:
A new
--build
argument has been added tobin/ember-cli
for thiscase, 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 andset up by default.