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
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
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.
-
Factory definitions live in
`spec/factories/`
, named using the pluralization
of their corresponding model (
`User`
factories are defined in
`users.rb`
).
-
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
resulting record to pass validation.
-
When instantiating from a factory, don't supply
extraneous attributes tha
t
aren't
required by the test.
-
When instantiating from a factory, don't supply
attributes that aren'
t
required by the test.
-
Factories don't have to be limited to
`ActiveRecord`
objects.
[
See example
](
https://gitlab.com/gitlab-org/gitlab-ce/commit/0b8cefd3b2385a21cfed779bd659978c0402766d
)
.
[
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
...
...
@@ -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
markup necessary for the test.
> **Warning:** Keep in mind that a Rails view may change and
invalidate your test, but everything will still pass because your fixture
doesn't reflect the latest view.
> **Warning:** Keep in mind that a Rails view may change and
invalidate your test, but everything will still pass because your fixture
doesn't reflect the latest view.
-
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
...
...
@@ -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`
,
`spy`
, or
`double`
will do. Database persistence is slow!
-
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
Spinach or
`js: true`
in RSpec) unless it's _actually_ required for the test
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