Create a concrete guideline for feature tests(spec/features)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Description

According to the http://docs.gitlab.com/ce/development/testing.html#system-feature-tests, we should maintain feature specs with those rules.

• Feature specs should be named ROLE_ACTION_spec.rb, such as user_changes_password_spec.rb.
• Use only one feature block per feature spec file.
• Use scenario titles that describe the success and failure paths.
• Avoid scenario titles that add no information, such as "successfully".
• Avoid scenario titles that repeat the feature title.

However, some specs don't obey those rules. This causes a problem that it's hard to figure out duplication/unnecessary tests. And confuses developers how they should organize feature specs.

In addition, Capybara provides some specific aliases such as feature, given and scenario, but currently we mixing those with describe, let which is declared in rspec.

Proposal

• Add a new job in test stage (gitlab-ci.yml) to warn if developers violate rules. (e.g. static-analysis)
• If http://docs.gitlab.com/ce/development/testing.html#system-feature-tests is outdated, let's update documentation.

Links / references

/cc @rymai