2018-03-17 18:26:18 +05:30
|
|
|
# GitLab QA - Integration tests for GitLab
|
2017-08-17 22:00:37 +05:30
|
|
|
|
|
|
|
|
This directory contains integration tests for GitLab.
|
|
|
|
|
|
2018-03-17 18:26:18 +05:30
|
|
|
It is part of the [GitLab QA project](https://gitlab.com/gitlab-org/gitlab-qa).
|
2017-08-17 22:00:37 +05:30
|
|
|
|
2018-03-17 18:26:18 +05:30
|
|
|
## What is it?
|
2017-08-17 22:00:37 +05:30
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
1. Along with GitLab Docker Images we also build and publish GitLab QA images.
|
|
|
|
|
1. GitLab QA project uses these images to execute integration tests.
|
2018-03-17 18:26:18 +05:30
|
|
|
|
|
|
|
|
## 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](qa/page/README.md). 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](qa/page/README.md)
|
|
|
|
|
|
|
|
|
|
### 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](https://gitlab.com/gitlab-org/gitlab-qa#supported-environment-variables).
|
|
|
|
|
|
|
|
|
|
[GDK]: https://gitlab.com/gitlab-org/gitlab-development-kit/
|
