diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-10-19 03:10:29 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-10-19 03:10:29 +0300 |
commit | 7e1b27cedb9aa52f13f3d4120dac8cdb6cfc0dda (patch) | |
tree | 00fadf81a71b6d3e69c3bdbb2103158a6a913cc8 /doc/development/testing_guide | |
parent | 27f5b61b11bd3381662ab89e09492b6afdca57dd (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/testing_guide')
-rw-r--r-- | doc/development/testing_guide/end_to_end/feature_flags.md | 22 | ||||
-rw-r--r-- | doc/development/testing_guide/testing_migrations_guide.md | 31 |
2 files changed, 42 insertions, 11 deletions
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/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md index 757a70fb4e0..1254ed89d56 100644 --- a/doc/development/testing_guide/testing_migrations_guide.md +++ b/doc/development/testing_guide/testing_migrations_guide.md @@ -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` |