These kind of tests ensure that individual parts of the application work well together, without the overhead of the actual app environment (i.e. the browser). These tests should assert at the request/response level: status code, headers, body. They're useful to test permissions, redirections, what view is rendered etc.
These kind of tests ensure that individual parts of the application work well
together, without the overhead of the actual app environment (i.e. the browser).
These tests should assert at the request/response level: status code, headers,
body.
They're useful to test permissions, redirections, what view is rendered etc.
These kind of tests ensure the application works as expected from a user point
- https://en.wikipedia.org/wiki/System_testing
of view (aka black-box testing). These tests should test a happy path for a
- https://en.wikipedia.org/wiki/White-box_testing
given page or set of pages, and a test case should be added for any regression
These kind of tests ensure the GitLab *Rails* application (i.e.
`gitlab-ce`/`gitlab-ee`) works as expected from a *browser* point of view.
Note that:
- knowledge of the internals of the application are still required
- data needed for the tests are usually created directly using RSpec factories
- expectations are often set on the database or objects state
These tests should only be used when:
- the functionality/component being tested is small
- the internal state of the objects/database *needs* to be tested
- it cannot be tested at a lower level
For instance, to test the breadcrumbs on a given page, writing a system test
makes sense since it's a small component, which cannot be tested at the unit or
controller level.
Only test the happy path, but make sure to add a test case for any regression
that couldn't have been caught at lower levels with better tests (i.e. if a
that couldn't have been caught at lower levels with better tests (i.e. if a
regression is found, regression tests should be added at the lowest-level
regression is found, regression tests should be added at the lowest-level
possible).
possible).
| Tests path | Testing engine | Notes |
| Tests path | Testing engine | Notes |
| ---------- | -------------- | ----- |
| ---------- | -------------- | ----- |
| `spec/features/` | [Capybara] + [RSpec] | If your spec has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. |
| `spec/features/` | [Capybara] + [RSpec] | If your test has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. |
### Consider **not** writing a system test!
### Consider **not** writing a system test!
...
@@ -89,7 +113,7 @@ we have enough Unit & Integration tests), we shouldn't need to duplicate their
...
@@ -89,7 +113,7 @@ we have enough Unit & Integration tests), we shouldn't need to duplicate their
thorough testing at the System test level.
thorough testing at the System test level.
It's very easy to add tests, but a lot harder to remove or improve tests, so one
It's very easy to add tests, but a lot harder to remove or improve tests, so one
should take care of not introducing too many (slow and duplicated) specs.
should take care of not introducing too many (slow and duplicated) tests.
The reasons why we should follow these best practices are as follows:
The reasons why we should follow these best practices are as follows:
...
@@ -107,29 +131,33 @@ The reasons why we should follow these best practices are as follows:
...
@@ -107,29 +131,33 @@ The reasons why we should follow these best practices are as follows:
Rémy Coutable <remy@rymai.me>