Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Boxiang Sun
gitlab-ce
Commits
cedcc145
Commit
cedcc145
authored
Apr 09, 2016
by
Robert Speicher
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Minor Testing guide copyedits
[ci skip]
parent
955d027d
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
10 additions
and
8 deletions
+10
-8
doc/development/testing.md
doc/development/testing.md
+10
-8
No files found.
doc/development/testing.md
View file @
cedcc145
...
@@ -16,16 +16,18 @@ GitLab uses [factory_girl] as a test fixture replacement.
...
@@ -16,16 +16,18 @@ GitLab uses [factory_girl] as a test fixture replacement.
-
Factory definitions live in
`spec/factories/`
, named using the pluralization
-
Factory definitions live in
`spec/factories/`
, named using the pluralization
of their corresponding model (
`User`
factories are defined in
`users.rb`
).
of their corresponding model (
`User`
factories are defined in
`users.rb`
).
-
There should be only one top-level factory definition per file.
-
There should be only one top-level factory definition per file.
-
Make use of [Traits] to clean up definitions and usages.
-
FactoryGirl methods are mixed in to all RSpec groups. This means you can (and
should) call
`create(...)`
instead of
`FactoryGirl.create(...)`
.
-
Make use of [traits] to clean up definitions and usages.
-
When defining a factory, don't define attributes that are not required for the
-
When defining a factory, don't define attributes that are not required for the
resulting record to pass validation.
resulting record to pass validation.
-
When instantiating from a factory, don't supply
extraneous attributes tha
t
-
When instantiating from a factory, don't supply
attributes that aren'
t
aren't
required by the test.
required by the test.
-
Factories don't have to be limited to
`ActiveRecord`
objects.
-
Factories don't have to be limited to
`ActiveRecord`
objects.
[
See example
](
https://gitlab.com/gitlab-org/gitlab-ce/commit/0b8cefd3b2385a21cfed779bd659978c0402766d
)
.
[
See example
](
https://gitlab.com/gitlab-org/gitlab-ce/commit/0b8cefd3b2385a21cfed779bd659978c0402766d
)
.
[
factory_girl
]:
https://github.com/thoughtbot/factory_girl
[
factory_girl
]:
https://github.com/thoughtbot/factory_girl
[
T
raits
]:
http://www.rubydoc.info/gems/factory_girl/file/GETTING_STARTED.md#Traits
[
t
raits
]:
http://www.rubydoc.info/gems/factory_girl/file/GETTING_STARTED.md#Traits
## JavaScript
## JavaScript
...
@@ -40,9 +42,9 @@ the command line via `bundle exec teaspoon`, or via a web browser at
...
@@ -40,9 +42,9 @@ the command line via `bundle exec teaspoon`, or via a web browser at
`spec/javascripts/fixtures`
. They should contain the bare minimum amount of
`spec/javascripts/fixtures`
. They should contain the bare minimum amount of
markup necessary for the test.
markup necessary for the test.
> **Warning:** Keep in mind that a Rails view may change and
> **Warning:** Keep in mind that a Rails view may change and
invalidate your test, but everything will still pass because your fixture
invalidate your test, but everything will still pass because your fixture
doesn't reflect the latest view.
doesn't reflect the latest view.
-
Keep in mind that in a CI environment, these tests are run in a headless
-
Keep in mind that in a CI environment, these tests are run in a headless
browser and you will not have access to certain APIs, such as
browser and you will not have access to certain APIs, such as
...
@@ -102,7 +104,7 @@ Here are some things to keep in mind regarding test performance:
...
@@ -102,7 +104,7 @@ Here are some things to keep in mind regarding test performance:
-
Don't
`create`
an object when
`build`
,
`build_stubbed`
,
`attributes_for`
,
-
Don't
`create`
an object when
`build`
,
`build_stubbed`
,
`attributes_for`
,
`spy`
, or
`double`
will do. Database persistence is slow!
`spy`
, or
`double`
will do. Database persistence is slow!
-
Use
`create(:empty_project)`
instead of
`create(:project)`
when you don't need
-
Use
`create(:empty_project)`
instead of
`create(:project)`
when you don't need
the underlying repository. Filesystem operations are slow!
the underlying
Git
repository. Filesystem operations are slow!
-
Don't mark a feature as requiring JavaScript (through
`@javascript`
in
-
Don't mark a feature as requiring JavaScript (through
`@javascript`
in
Spinach or
`js: true`
in RSpec) unless it's _actually_ required for the test
Spinach or
`js: true`
in RSpec) unless it's _actually_ required for the test
to be valid. Headless browser testing is slow!
to be valid. Headless browser testing is slow!
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment