summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRémy Coutable <remy@rymai.me>2017-04-12 11:19:47 +0200
committerRémy Coutable <remy@rymai.me>2017-04-12 11:19:47 +0200
commita7e8939d2f36e7db9be3d7ee9960a48354cedcd3 (patch)
tree58f3e848885d84274ca2adf08a3e817c8637c432
parent6de5aad237d3fd2edf987c5f2a4f38c16b2375ac (diff)
downloadgitlab-ce-improve-testing-documentation.tar.gz
Improve the testing documentationimprove-testing-documentation
Signed-off-by: Rémy Coutable <remy@rymai.me>
-rw-r--r--doc/development/testing.md46
1 files changed, 23 insertions, 23 deletions
diff --git a/doc/development/testing.md b/doc/development/testing.md
index 0d02b7ca597..ad540ec13db 100644
--- a/doc/development/testing.md
+++ b/doc/development/testing.md
@@ -95,29 +95,6 @@ possible).
[Poltergeist]: https://github.com/teamcapybara/capybara#poltergeist
[RackTest]: https://github.com/teamcapybara/capybara#racktest
-### Black-box tests or End-to-end tests
-
-GitLab consists of [multiple pieces] such as [GitLab Shell], [GitLab Workhorse],
-[Gitaly], [GitLab Pages], [GitLab Runner], and GitLab Rails. All theses pieces
-are configured and packaged by [GitLab Omnibus].
-
-[GitLab QA] is a tool that allows to test that all these pieces integrate well
-together by building a Docker image for a given version of GitLab Rails and
-running feature tests (i.e. using Capybara) against it.
-
-The actual test scenarios and steps are [part of GitLab Rails] so that they're
-always in-sync with the codebase.
-
-[multiple pieces]: ./architecture.md#components
-[GitLab Shell]: https://gitlab.com/gitlab-org/gitlab-shell
-[GitLab Workhorse]: https://gitlab.com/gitlab-org/gitlab-workhorse
-[Gitaly]: https://gitlab.com/gitlab-org/gitaly
-[GitLab Pages]: https://gitlab.com/gitlab-org/gitlab-pages
-[GitLab Runner]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
-[GitLab Omnibus]: https://gitlab.com/gitlab-org/omnibus-gitlab
-[GitLab QA]: https://gitlab.com/gitlab-org/gitlab-qa
-[part of GitLab Rails]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa
-
#### Best practices
- Create only the necessary records in the database
@@ -150,6 +127,29 @@ The reasons why we should follow these best practices are as follows:
of tests). This is slower than transactions, however, so we want to use
truncation only when necessary.
+### Black-box tests or End-to-end tests
+
+GitLab consists of [multiple pieces] such as [GitLab Shell], [GitLab Workhorse],
+[Gitaly], [GitLab Pages], [GitLab Runner], and GitLab Rails. All theses pieces
+are configured and packaged by [GitLab Omnibus].
+
+[GitLab QA] is a tool that allows to test that all these pieces integrate well
+together by building a Docker image for a given version of GitLab Rails and
+running feature tests (i.e. using Capybara) against it.
+
+The actual test scenarios and steps are [part of GitLab Rails] so that they're
+always in-sync with the codebase.
+
+[multiple pieces]: ./architecture.md#components
+[GitLab Shell]: https://gitlab.com/gitlab-org/gitlab-shell
+[GitLab Workhorse]: https://gitlab.com/gitlab-org/gitlab-workhorse
+[Gitaly]: https://gitlab.com/gitlab-org/gitaly
+[GitLab Pages]: https://gitlab.com/gitlab-org/gitlab-pages
+[GitLab Runner]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
+[GitLab Omnibus]: https://gitlab.com/gitlab-org/omnibus-gitlab
+[GitLab QA]: https://gitlab.com/gitlab-org/gitlab-qa
+[part of GitLab Rails]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa
+
## How to test at the correct level?
As many things in life, deciding what to test at each level of testing is a