Audit Reliable test names in 9_data_stores
Description of the test
Updating test naming of the Reliable tests in 9_data_stores to match the new standard
How to set up and validate locally
From the qa
directory:
bundle install
export WEBDRIVER_HEADLESS=false # If you'd like to watch the test in action
export QA_GITLAB_URL="http://gdk.test:3000" # Only needed if GDK is not running on http://127.0.0.1:3000
bundle exec rspec --tag reliable ./qa/specs/features/browser_ui/9_data_stores/
As a quick check you could also run rspec in dry run mode, the logic of the tests did not change, just the names.
bundle exec rspec --tag reliable --dry-run ./qa/specs/features/browser_ui/9_data_stores/
Checklist
-
Confirm the test has a testcase:
tag linking to an existing test case in the test case project. -
Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario. -
Follow the end-to-end tests style guide and best practices. -
Use the appropriate RSpec metadata tag(s). - Most resources will be cleaned up via the general cleanup task. Check that is successful, or ensure resources are cleaned up in the test:
-
New resources have api_get_path
andapi_delete_path
implemented if possible. -
If any resource cannot be deleted in the general delete task, make sure it is ignored. -
If any resource cannot be deleted in the general delete task, remove it in the test (e.g., in an after
block).
-
-
Ensure that no transient bugs are hidden accidentally due to the usage of waits
andreloads
. -
Verify the tags to ensure it runs on the desired test environments. -
If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the GITLAB_QA_ADMIN_ACCESS_TOKEN
provided.
Edited by Andy Hohenner