This directory contains integration tests for GitLab.
It is part of the GitLab QA project.
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.
- When we release a new version of GitLab, we build a Docker images for it.
- Along with GitLab Docker Images we also build and publish GitLab QA images.
- GitLab QA project uses these images to execute integration tests.
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.
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
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
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