gitlab-org--gitlab-foss/qa
Kamil Trzciński a55cfc1e63 Merge branch 'ce-39118-dynamic-pipeline-variables-fe' into 'master'
Dynamic CI secret variables -- CE backport

See merge request gitlab-org/gitlab-ce!16842
2018-02-07 12:23:36 +00:00
..
bin Fix bootable scenario arguments for OptionParser 2017-11-10 11:11:22 +00:00
qa Merge branch 'ce-39118-dynamic-pipeline-variables-fe' into 'master' 2018-02-07 12:23:36 +00:00
spec Expand QA spec file paths to allow running bin/qa from anywhere 2018-02-06 12:34:45 -06:00
.gitignore Make it possible to define global scenario attributes 2017-11-09 11:53:57 +00:00
.rspec
Dockerfile Use new Ruby version 2.4 in GitLab QA images 2017-12-14 11:21:57 +01:00
Gemfile Merge remote-tracking branch 'upstream/master' into qa-deploy-key-scenario 2018-01-24 23:13:56 +08:00
Gemfile.lock Merge remote-tracking branch 'upstream/master' into qa-deploy-key-scenario 2018-01-24 23:13:56 +08:00
qa.rb Address review comments for LDAP QA test 2018-02-06 16:27:37 -08:00
README.md Revert "Merge branch 'update-qa-docs-with-directory-req' into 'master'" 2018-02-06 12:34:45 -06:00

GitLab QA - Integration tests for GitLab

This directory contains integration tests for GitLab.

It is part of the GitLab QA project.

What is it?

GitLab QA is an integration tests suite for GitLab.

These are black-box and entirely click-driven integration tests you can run against any existing instance.

How does it work?

  1. When we release a new version of GitLab, we build a Docker images for it.
  2. Along with GitLab Docker Images we also build and publish GitLab QA images.
  3. GitLab QA project uses these images to execute integration tests.

Validating GitLab views / partials / selectors in merge requests

We recently added a new CI job that is going to be triggered for every push event in CE and EE projects. The job is called qa:selectors and it will verify coupling between page objects implemented as a part of GitLab QA and corresponding views / partials / selectors in CE / EE.

Whenever qa:selectors job fails in your merge request, you are supposed to fix page objects. You should also trigger end-to-end tests using package-qa manual action, to test if everything works fine.

How can I use it?

You can use GitLab QA to exercise tests on any live instance! For example, the following call would login to a local GDK instance and run all specs in qa/specs/features:

bin/qa Test::Instance http://localhost:3000

Writing tests

  1. Using page objects

Running specific tests

You can also supply specific tests to run as another parameter. For example, to run the repository-related specs, you can execute:

bin/qa Test::Instance http://localhost qa/specs/features/repository/

Since the arguments would be passed to rspec, you could use all rspec options there. For example, passing --backtrace and also line number:

bin/qa Test::Instance http://localhost qa/specs/features/login/standard_spec.rb:3 --backtrace

Overriding the authenticated user

Unless told otherwise, the QA tests will run as the default root user seeded by the GDK.

If you need to authenticate as a different user, you can provide the GITLAB_USERNAME and GITLAB_PASSWORD environment variables:

GITLAB_USERNAME=jsmith GITLAB_PASSWORD=password bin/qa Test::Instance https://gitlab.example.com

All supported environment variables are here.