diff options
Diffstat (limited to 'doc/development/testing_guide')
9 files changed, 294 insertions, 87 deletions
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 52e89a10556..6a739d9e1a5 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -50,6 +50,23 @@ bundle exec guard When using spring and guard together, use `SPRING=1 bundle exec guard` instead to make use of spring. +### Eager loading the application code + +By default, the application code: + +- Isn't eagerly loaded in the `test` environment. +- Is eagerly loaded in CI/CD (when `ENV['CI'].present?`) to surface any potential loading issues. + +If you need to enable eager loading when executing tests, +use the `GITLAB_TEST_EAGER_LOAD` environment variable: + +```shell +GITLAB_TEST_EAGER_LOAD=1 bin/rspec spec/models/project_spec.rb +``` + +If your test depends on all the application code that is being loaded, add the `:eager_load` tag. +This ensures that the application code is eagerly loaded before the test execution. + ### Ruby warnings > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47767) in GitLab 13.7. diff --git a/doc/development/testing_guide/end_to_end/beginners_guide.md b/doc/development/testing_guide/end_to_end/beginners_guide.md index 7370cc5771b..27a87d25170 100644 --- a/doc/development/testing_guide/end_to_end/beginners_guide.md +++ b/doc/development/testing_guide/end_to_end/beginners_guide.md @@ -350,7 +350,7 @@ GITLAB_PASSWORD=<GDK root password> bundle exec bin/qa Test::Instance::All http: Where `<test_file>` is: - `qa/specs/features/browser_ui/1_manage/login/log_in_spec.rb` when running the Login example. -- `qa/specs/features/browser_ui/2_plan/issues/create_issue_spec.rb` when running the Issue example. +- `qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb` when running the Issue example. ## End-to-end test merge request template diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md index 994ee3f253c..52212410cc6 100644 --- a/doc/development/testing_guide/end_to_end/feature_flags.md +++ b/doc/development/testing_guide/end_to_end/feature_flags.md @@ -79,11 +79,21 @@ for details. End-to-end tests should pass with a feature flag enabled before it is enabled on Staging or on GitLab.com. Tests that need to be updated should be identified as part of [quad-planning](https://about.gitlab.com/handbook/engineering/quality/quad-planning/). The relevant [counterpart Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) is responsible for updating the tests or assisting another engineer to do so. However, if a change does not go through quad-planning and a required test update is not made, test failures could block deployment. -If a test enables a feature flag as describe above, it is sufficient to run the `package-and-qa` job in a merge request containing the relevant changes. -Or, if the feature flag and relevant changes have already been merged, you can confirm that the tests -pass on `main`. The end-to-end tests run on `main` every two hours, and the results are posted to a [Test -Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amaster). +### Automatic test execution when a feature flag definition changes -If the relevant tests do not enable the feature flag themselves, you can check if the tests will need -to be updated by opening a draft merge request that enables the flag by default and then running the `package-and-qa` job. +If a merge request adds or edits a [feature flag definition file](../../feature_flags/index.md#feature-flag-definition-and-validation), +two `package-and-qa` jobs will be included automatically in the merge request pipeline. One job will enable the defined +feature flag and the other will disable it. The jobs execute the same suite of tests to confirm that they pass with if +the feature flag is either enabled or disabled. + +### Test execution during feature development + +If an end-to-end test enables a feature flag, the end-to-end test suite can be used to test changes in a merge request +by running the `package-and-qa` job in the merge request pipeline. If the feature flag and relevant changes have already been merged, you can confirm that the tests +pass on the default branch. The end-to-end tests run on the default branch every two hours, and the results are posted to a [Test +Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amain). + +If the relevant tests do not enable the feature flag themselves, you can check if the tests will need to be updated by opening +a draft merge request that enables the flag by default via a [feature flag definition file](../../feature_flags/index.md#feature-flag-definition-and-validation). +That will [automatically execute the end-to-end test suite](#automatic-test-execution-when-a-feature-flag-definition-changes). The merge request can be closed once the tests pass. If you need assistance to update the tests, please contact the relevant [stable counterpart in the Quality department](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors), or any Software Engineer in Test if there is no stable counterpart for your group. diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md index b097d6b0729..57c8c3bf59c 100644 --- a/doc/development/testing_guide/end_to_end/index.md +++ b/doc/development/testing_guide/end_to_end/index.md @@ -147,7 +147,7 @@ as well as these: | Variable | Description | |-|-| | `QA_SCENARIO` | The scenario to run (default `Test::Instance::Image`) | -| `QA_TESTS` | The test(s) to run (no default, which means run all the tests in the scenario). Use file paths as you would when running tests via RSpec, e.g., `qa/specs/features/ee/browser_ui` would include all the `EE` UI tests. | +| `QA_TESTS` | The test(s) to run (no default, which means run all the tests in the scenario). Use file paths as you would when running tests via RSpec, for example, `qa/specs/features/ee/browser_ui` would include all the `EE` UI tests. | | `QA_RSPEC_TAGS` | The RSpec tags to add (no default) | For now [manual jobs with custom variables don't use the same variable diff --git a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md index eadd0ef49a0..95984a701e7 100644 --- a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md +++ b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md @@ -165,20 +165,20 @@ QA_DEBUG=true WEBDRIVER_HEADLESS=false GITLAB_ADMIN_USERNAME=rootusername GITLAB The following includes more information on the command: --`QA_DEBUG` - Set to `true` to verbosely log page object actions. --`WEBDRIVER_HEADLESS` - When running locally, set to `false` to allow browser tests to be visible - watch your tests being run. --`GITLAB_ADMIN_USERNAME` - Administrator username to use when adding a license. --`GITLAB_ADMIN_PASSWORD` - Administrator password to use when adding a license. --`GITLAB_QA_ACCESS_TOKEN` and `GITLAB_QA_ADMIN_ACCESS_TOKEN` - A valid personal access token with the `api` scope. This is used for API access during tests, and is used in the version that staging is currently running. The `ADMIN_ACCESS_TOKEN` is from a user with administrator access. Used for API access as an administrator during tests. --`CLUSTER_API_URL` - Use the address `https://kubernetes.docker.internal:6443` . This address is used to enable the cluster to be network accessible while deploying using Auto DevOps. --`https://[YOUR-PORT].qa-tunnel.gitlab.info/` - The address of your local GDK --`qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb` - The path to the monitor core specs --`--tag` - the meta-tags used to filter the specs correctly +- `QA_DEBUG` - Set to `true` to verbosely log page object actions. +- `WEBDRIVER_HEADLESS` - When running locally, set to `false` to allow browser tests to be visible - watch your tests being run. +- `GITLAB_ADMIN_USERNAME` - Administrator username to use when adding a license. +- `GITLAB_ADMIN_PASSWORD` - Administrator password to use when adding a license. +- `GITLAB_QA_ACCESS_TOKEN` and `GITLAB_QA_ADMIN_ACCESS_TOKEN` - A valid personal access token with the `api` scope. This is used for API access during tests, and is used in the version that staging is currently running. The `ADMIN_ACCESS_TOKEN` is from a user with administrator access. Used for API access as an administrator during tests. +- `CLUSTER_API_URL` - Use the address `https://kubernetes.docker.internal:6443` . This address is used to enable the cluster to be network accessible while deploying using Auto DevOps. +- `https://[YOUR-PORT].qa-tunnel.gitlab.info/` - The address of your local GDK +- `qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb` - The path to the monitor core specs +- `--tag` - the meta-tags used to filter the specs correctly At the moment of this writing, there are two specs which run monitor tests: --`qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb` - has the specs of features in GitLab Free --`qa/specs/features/ee/browser_ui/8_monitor/all_monitor_features_spec.rb` - has the specs of features for paid GitLab (Enterprise Edition) +- `qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb` - has the specs of features in GitLab Free +- `qa/specs/features/ee/browser_ui/8_monitor/all_monitor_features_spec.rb` - has the specs of features for paid GitLab (Enterprise Edition) ### How to debug @@ -485,3 +485,109 @@ To run the LDAP tests on your local with TLS disabled, follow these steps: ```shell GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb ``` + +## Guide to the mobile suite + +### What are mobile tests + +Tests that are tagged with `:mobile` can be run against specified mobile devices using cloud emulator/simulator services. + +### How to run mobile tests with Sauce Labs + +Running directly against an environment like staging is not recommended because Sauce Labs test logs expose credentials. Therefore, it is best practice and the default to use a tunnel. + +Tunnel installation instructions are here [https://docs.saucelabs.com/secure-connections/sauce-connect/installation]. To start the tunnel, after following the installation above, copy the run command in Sauce Labs > Tunnels (must be logged in to Sauce Labs with the credentials found in 1Password) and run in terminal. + +NOTE: +It is highly recommended to use `GITLAB_QA_ACCESS_TOKEN` to speed up tests and reduce flakiness. + +`QA_REMOTE_MOBILE_DEVICE_NAME` can be any device name listed in [https://saucelabs.com/platform/supported-browsers-devices] under Emulators/simulators and the latest versions of Android or iOS. `QA_BROWSER` must be set to `safari` for iOS devices and `chrome` for Android devices. + +1. To test against a local instance with a tunnel running, in `gitlab/qa` run: + +```shell +$ QA_BROWSER="safari" \ + QA_REMOTE_MOBILE_DEVICE_NAME="iPhone 12 Simulator" \ + QA_REMOTE_GRID="ondemand.saucelabs.com:80" \ + QA_REMOTE_GRID_USERNAME="gitlab-sl" \ + QA_REMOTE_GRID_ACCESS_KEY="<found in Sauce Lab account>" \ + GITLAB_QA_ACCESS_TOKEN="<token>" \ + bundle exec bin/qa Test::Instance::All http://<local_ip>:3000 -- <relative_spec_path> +``` + +Results can be watched in real time while logged into Sauce Labs under AUTOMATED > Test Results. + +### How to add an existing test to the mobile suite + +The main reason a test might fail when adding the `:mobile` tag is navigation differences in desktop vs mobile layouts, therefore the test needs to be updated to use mobile navigation when running mobile tests. + +If an existing method needs to be changed or a new one created, a new mobile page object should be created in `qa/qa/mobile/page/` and it should be prepended in the original page object by adding: + +```ruby +prepend Mobile::Page::NewPageObject if Runtime::Env.mobile_layout? +``` + +For example to change an existing method when running mobile tests: + +New mobile page object: + +```ruby +module QA + module Mobile + module Page + module Project + module Show + extend QA::Page::PageConcern + + def self.prepended(base) + super + + base.class_eval do + prepend QA::Mobile::Page::Main::Menu + + view 'app/assets/javascripts/nav/components/top_nav_new_dropdown.vue' do + element :new_issue_mobile_button + end + end + end + + def go_to_new_issue + open_mobile_new_dropdown + + click_element(:new_issue_mobile_button) + end + end + end + end + end +end +``` + +Original page object prepending the new mobile if there's a mobile layout: + +```ruby +module QA + module Page + module Project + class Show < Page::Base + prepend Mobile::Page::Project::Show if Runtime::Env.mobile_layout? + + view 'app/views/layouts/header/_new_dropdown.html.haml' do + element :new_menu_toggle + end + + view 'app/helpers/nav/new_dropdown_helper.rb' do + element :new_issue_link + end + + def go_to_new_issue + click_element(:new_menu_toggle) + click_element(:new_issue_link) + end + end + end + end +end +``` + +When running mobile tests for phone layouts, both `remote_mobile_device_name` and `mobile_layout` are `true` but when using a tablet layout, only `remote_mobile_device_name` is true. This is because phone layouts have more menus closed by default such as how both tablets and phones have the left nav closed but unlike phone layouts, tablets have the regular top navigation bar, not the mobile one. So in the case where the navigation being edited needs to be used in tablet layouts as well, use `remote_mobile_device_name` instead of `mobile_layout?` when prepending so it will use it if it's a tablet layout as well. diff --git a/doc/development/testing_guide/end_to_end/style_guide.md b/doc/development/testing_guide/end_to_end/style_guide.md index 22ddae6e836..a9571df1188 100644 --- a/doc/development/testing_guide/end_to_end/style_guide.md +++ b/doc/development/testing_guide/end_to_end/style_guide.md @@ -14,7 +14,7 @@ This document describes the conventions used at GitLab for writing End-to-end (E When clicking in a single link to navigate, use `click_`. -E.g.: +For example: ```ruby def click_ci_cd_pipelines @@ -33,7 +33,7 @@ From a testing perspective, if we want to check that clicking a link, or a butto When interacting with multiple elements to go to a page, use `go_to_`. -E.g.: +For example: ```ruby def go_to_operations_environments @@ -63,12 +63,12 @@ We follow a simple formula roughly based on Hungarian notation. - `type`: A generic control on the page that can be seen by a user. - `_button` - `_checkbox` - - `_container`: an element that includes other elements, but doesn't present visible content itself. E.g., an element that has a third-party editor inside it, but which isn't the editor itself and so doesn't include the editor's content. + - `_container`: an element that includes other elements, but doesn't present visible content itself. For example, an element that has a third-party editor inside it, but which isn't the editor itself and so doesn't include the editor's content. - `_content`: any element that contains text, images, or any other content displayed to the user. - `_dropdown` - `_field`: a text input element. - `_link` - - `_modal`: a popup modal dialog, e.g., a confirmation prompt. + - `_modal`: a popup modal dialog, for example, a confirmation prompt. - `_placeholder`: a temporary element that appears while content is loading. For example, the elements that are displayed instead of discussions while the discussions are being fetched. - `_radio` - `_tab` @@ -116,7 +116,7 @@ we use the name of the page object in [snake_case](https://en.wikipedia.org/wiki (all lowercase, with words separated by an underscore). See good and bad examples below. While we prefer to follow the standard in most cases, it is also acceptable to -use common abbreviations (e.g., `mr`) or other alternatives, as long as +use common abbreviations (for example, `mr`) or other alternatives, as long as the name is not ambiguous. This can include appending `_page` if it helps to avoid confusion or make the code more readable. For example, if a page object is named `New`, it could be confusing to name the block argument `new` because that diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index 0e721ba2760..3096386d7c3 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -423,7 +423,8 @@ it('passes', () => { ### Waiting in tests Sometimes a test needs to wait for something to happen in the application before it continues. -Avoid using [`setTimeout`](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout) +Avoid using [`setTimeout`](https://developer.mozilla.org/en-US/docs/Web/API/setTimeout) + because it makes the reason for waiting unclear. Instead use one of the following approaches. #### Promises and Ajax calls diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md index 4091f213a8f..3190ab6c899 100644 --- a/doc/development/testing_guide/review_apps.md +++ b/doc/development/testing_guide/review_apps.md @@ -16,6 +16,7 @@ For any of the following scenarios, the `start-review-app-pipeline` job would be - for merge requests with frontend changes - for merge requests with QA changes - for scheduled pipelines +- the MR has the `pipeline:run-review-app` label set ## QA runs on Review Apps @@ -37,6 +38,15 @@ browser performance testing using a ## How to +### Redeploy Review App from a clean slate + +To reset Review App and redeploy from a clean slate, do the following: + +1. Run `review-stop` job. +1. Re-deploy by running or retrying `review-deploy` job. + +Doing this will remove all existing data from a previously deployed Review App. + ### Get access to the GCP Review Apps cluster You need to [open an access request (internal link)](https://gitlab.com/gitlab-com/access-requests/-/issues/new) @@ -180,7 +190,7 @@ subgraph "CNG-mirror pipeline" **Additional notes:** - If the `review-deploy` job keeps failing (and a manual retry didn't help), - please post a message in the `#g_qe_engineering_productivity` channel and/or create a `~"Engineering Productivity"` `~"ep::review apps"` `~bug` + please post a message in the `#g_qe_engineering_productivity` channel and/or create a `~"Engineering Productivity"` `~"ep::review apps"` `~"type::bug"` issue with a link to your merge request. Note that the deployment failure can reveal an actual problem introduced in your merge request (i.e. this isn't necessarily a transient failure)! @@ -189,7 +199,7 @@ subgraph "CNG-mirror pipeline" your merge request. You can also download the artifacts to see screenshots of the page at the time the failures occurred. If you don't find the cause of the failure or if it seems unrelated to your change, please post a message in the - `#quality` channel and/or create a ~Quality ~bug issue with a link to your + `#quality` channel and/or create a ~Quality ~"type::bug" issue with a link to your merge request. - The manual `review-stop` can be used to stop a Review App manually, and is also started by GitLab once a merge @@ -238,6 +248,16 @@ Leading indicators may be health check failures leading to restarts or majority The [Review Apps Overview dashboard](https://console.cloud.google.com/monitoring/classic/dashboards/6798952013815386466?project=gitlab-review-apps&timeDomain=1d) aids in identifying load spikes on the cluster, and if nodes are problematic or the entire cluster is trending towards unhealthy. +### Database related errors in `review-deploy` or `review-qa-smoke` + +Occasionally the state of a Review App's database could diverge from the database schema. This could be caused by +changes to migration files or schema, such as a migration being renamed or deleted. This typically manifest in migration errors such as: + +- migration job failing with a column that already exists +- migration job failing with a column that does not exist + +To recover from this, please attempt to [redeploy Review App from a clean slate](#redeploy-review-app-from-a-clean-slate) + ### Release failed with `ImagePullBackOff` **Potential cause:** diff --git a/doc/development/testing_guide/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md index 757a70fb4e0..4092c1a2f6d 100644 --- a/doc/development/testing_guide/testing_migrations_guide.md +++ b/doc/development/testing_guide/testing_migrations_guide.md @@ -38,7 +38,7 @@ ensures proper isolation. ## Testing an `ActiveRecord::Migration` class -To test an `ActiveRecord::Migration` class (i.e., a +To test an `ActiveRecord::Migration` class (for example, a regular migration `db/migrate` or a post-migration `db/post_migrate`), you must load the migration file by using the `require_migration!` helper method because it is not autoloaded by Rails. @@ -61,14 +61,35 @@ Since the migration files are not autoloaded by Rails, you must manually load the migration file. To do so, you can use the `require_migration!` helper method which can automatically load the correct migration file based on the spec filename. -For example, if your spec file is named as `populate_foo_column_spec.rb` then the -helper method tries to load `${schema_version}_populate_foo_column.rb` migration file. +In GitLab 14.4 and later, you can use `require_migration!` to load migration files from spec files +that contain the schema version in the filename (for example, +`2021101412150000_populate_foo_column_spec.rb`). -In case there is no pattern between your spec file and the actual migration file, -you can provide the migration filename without the schema version, like so: +```ruby +# frozen_string_literal: true + +require 'spec_helper' +require_migration! + +RSpec.describe PopulateFooColumn do + ... +end +``` + +In some cases, you must require multiple migration files to use them in your specs. Here, there's no +pattern between your spec file and the other migration file. You can provide the migration filename +like so: ```ruby -require_migration!('populate_foo_column') +# frozen_string_literal: true + +require 'spec_helper' +require_migration! +require_migration!('populate_bar_column') + +RSpec.describe PopulateFooColumn do + ... +end ``` #### `table` @@ -213,54 +234,65 @@ Migration tests depend on what the migration does exactly, the most common types #### Example of a data migration test This spec tests the -[`db/post_migrate/20170526185842_migrate_pipeline_stages.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/db/post_migrate/20170526185842_migrate_pipeline_stages.rb) +[`db/post_migrate/20200723040950_migrate_incident_issues_to_incident_type.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20200723040950_migrate_incident_issues_to_incident_type.rb) migration. You can find the complete spec in -[`spec/migrations/migrate_pipeline_stages_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/spec/migrations/migrate_pipeline_stages_spec.rb). +[`spec/migrations/migrate_incident_issues_to_incident_type_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/migrations/migrate_incident_issues_to_incident_type_spec.rb). ```ruby -require 'spec_helper' +# frozen_string_literal: true +require 'spec_helper' require_migration! -RSpec.describe MigratePipelineStages do - # Create test data - pipeline and CI/CD jobs. - let(:jobs) { table(:ci_builds) } - let(:stages) { table(:ci_stages) } - let(:pipelines) { table(:ci_pipelines) } +RSpec.describe MigrateIncidentIssuesToIncidentType do + let(:migration) { described_class.new } + let(:projects) { table(:projects) } + let(:namespaces) { table(:namespaces) } + let(:labels) { table(:labels) } + let(:issues) { table(:issues) } + let(:label_links) { table(:label_links) } + let(:label_props) { IncidentManagement::CreateIncidentLabelService::LABEL_PROPERTIES } + + let(:namespace) { namespaces.create!(name: 'foo', path: 'foo') } + let!(:project) { projects.create!(namespace_id: namespace.id) } + let(:label) { labels.create!(project_id: project.id, **label_props) } + let!(:incident_issue) { issues.create!(project_id: project.id) } + let!(:other_issue) { issues.create!(project_id: project.id) } + + # Issue issue_type enum + let(:issue_type) { 0 } + let(:incident_type) { 1 } before do - projects.create!(id: 123, name: 'gitlab1', path: 'gitlab1') - pipelines.create!(id: 1, project_id: 123, ref: 'master', sha: 'adf43c3a') - jobs.create!(id: 1, commit_id: 1, project_id: 123, stage_idx: 2, stage: 'build') - jobs.create!(id: 2, commit_id: 1, project_id: 123, stage_idx: 1, stage: 'test') + label_links.create!(target_id: incident_issue.id, label_id: label.id, target_type: 'Issue') end - # Test just the up migration. - it 'correctly migrates pipeline stages' do - expect(stages.count).to be_zero - - migrate! + describe '#up' do + it 'updates the incident issue type' do + expect { migrate! } + .to change { incident_issue.reload.issue_type } + .from(issue_type) + .to(incident_type) - expect(stages.count).to eq 2 - expect(stages.all.pluck(:name)).to match_array %w[test build] + expect(other_issue.reload.issue_type).to eql(issue_type) + end end - # Test a reversible migration. - it 'correctly migrates up and down pipeline stages' do - reversible_migration do |migration| - # Expectations will run before the up migration, - # and then again after the down migration - migration.before -> { - expect(stages.count).to be_zero - } - - # Expectations will run after the up migration. - migration.after -> { - expect(stages.count).to eq 2 - expect(stages.all.pluck(:name)).to match_array %w[test build] - } + describe '#down' do + let!(:incident_issue) { issues.create!(project_id: project.id, issue_type: issue_type) } + + it 'updates the incident issue type' do + migration.up + + expect { migration.down } + .to change { incident_issue.reload.issue_type } + .from(incident_type) + .to(issue_type) + + expect(other_issue.reload.issue_type).to eql(issue_type) end + end end ``` @@ -336,41 +368,62 @@ end ### Example background migration test This spec tests the -[`lib/gitlab/background_migration/archive_legacy_traces.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/lib/gitlab/background_migration/archive_legacy_traces.rb) +[`lib/gitlab/background_migration/backfill_draft_status_on_merge_requests.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/background_migration/backfill_draft_status_on_merge_requests.rb) background migration. You can find the complete spec on -[`spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb) +[`spec/lib/gitlab/background_migration/backfill_draft_status_on_merge_requests_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/background_migration/backfill_draft_status_on_merge_requests_spec.rb) ```ruby +# frozen_string_literal: true + require 'spec_helper' -describe Gitlab::BackgroundMigration::ArchiveLegacyTraces, schema: 20180529152628 do - include TraceHelpers +RSpec.describe Gitlab::BackgroundMigration::BackfillDraftStatusOnMergeRequests do + let(:namespaces) { table(:namespaces) } + let(:projects) { table(:projects) } + let(:merge_requests) { table(:merge_requests) } - let(:namespaces) { table(:namespaces) } - let(:projects) { table(:projects) } - let(:builds) { table(:ci_builds) } - let(:job_artifacts) { table(:ci_job_artifacts) } + let(:group) { namespaces.create!(name: 'gitlab', path: 'gitlab') } + let(:project) { projects.create!(namespace_id: group.id) } - before do - namespaces.create!(id: 123, name: 'gitlab1', path: 'gitlab1') - projects.create!(id: 123, name: 'gitlab1', path: 'gitlab1', namespace_id: 123) - @build = builds.create!(id: 1, project_id: 123, status: 'success', type: 'Ci::Build') + let(:draft_prefixes) { ["[Draft]", "(Draft)", "Draft:", "Draft", "[WIP]", "WIP:", "WIP"] } + + def create_merge_request(params) + common_params = { + target_project_id: project.id, + target_branch: 'feature1', + source_branch: 'master' + } + + merge_requests.create!(common_params.merge(params)) end - context 'when trace file exists at the right place' do + context "for MRs with #draft? == true titles but draft attribute false" do + let(:mr_ids) { merge_requests.all.collect(&:id) } + before do - create_legacy_trace(@build, 'trace in file') + draft_prefixes.each do |prefix| + (1..4).each do |n| + create_merge_request( + title: "#{prefix} This is a title", + draft: false, + state_id: n + ) + end + end end - it 'correctly archive legacy traces' do - expect(job_artifacts.count).to eq(0) - expect(File.exist?(legacy_trace_path(@build))).to be_truthy + it "updates all open draft merge request's draft field to true" do + mr_count = merge_requests.all.count + + expect { subject.perform(mr_ids.first, mr_ids.last) } + .to change { MergeRequest.where(draft: false).count } + .from(mr_count).to(mr_count - draft_prefixes.length) + end - described_class.new.perform(1, 1) + it "marks successful slices as completed" do + expect(subject).to receive(:mark_job_as_succeeded).with(mr_ids.first, mr_ids.last) - expect(job_artifacts.count).to eq(1) - expect(File.exist?(legacy_trace_path(@build))).to be_falsy - expect(File.read(archived_trace_path(job_artifacts.first))).to eq('trace in file') + subject.perform(mr_ids.first, mr_ids.last) end end end |