The purpose of this guide is to document potential "gotchas" that contributors might encounter or should avoid during development of GitLab CE and EE.
Consider the following model spec:
require 'rails_helper'
describe User do
describe :to_param do
it 'converts the username to a param' do
user = described_class.new(username: 'John Smith')
expect(user.to_param).to eq 'john-smith'
end
end
end
When run, this spec doesn't do what we might expect:
spec/models/user_spec.rb|6 error| Failure/Error: u = described_class.new NoMethodError: undefined method `new' for :to_param:Symbol
Except for the top-level describe
block, always provide a String argument to
describe
.
Consider the following factory:
FactoryGirl.define do
factory :label do
sequence(:title) { |n| "label#{n}" }
end
end
Consider the following API spec:
require 'rails_helper'
describe API::Labels do
it 'creates a first label' do
create(:label)
get api("/projects/#{project.id}/labels", user)
expect(response).to have_http_status(200)
expect(json_response.first['name']).to eq('label1')
end
it 'creates a second label' do
create(:label)
get api("/projects/#{project.id}/labels", user)
expect(response).to have_http_status(200)
expect(json_response.first['name']).to eq('label1')
end
end
When run, this spec doesn't do what we might expect:
1) API::API reproduce sequence issue creates a second label
Failure/Error: expect(json_response.first['name']).to eq('label1')
expected: "label1"
got: "label2"
(compared using ==)
That's because FactoryGirl sequences are not reseted for each example.
Please remember that sequence-generated values exist only to avoid having to explicitly set attributes that have a uniqueness constraint when using a factory.
If you assert against a sequence-generated attribute's value, you should set it explicitly. Also, the value you set shouldn't match the sequence pattern.
For instance, using our :label
factory, writing create(:label, title: 'foo')
is ok, but create(:label, title: 'label1')
is not.
Following is the fixed API spec:
require 'rails_helper'
describe API::Labels do
it 'creates a first label' do
create(:label, title: 'foo')
get api("/projects/#{project.id}/labels", user)
expect(response).to have_http_status(200)
expect(json_response.first['name']).to eq('foo')
end
it 'creates a second label' do
create(:label, title: 'bar')
get api("/projects/#{project.id}/labels", user)
expect(response).to have_http_status(200)
expect(json_response.first['name']).to eq('bar')
end
end
See "Why is it bad style to rescue Exception => e
in Ruby?".
Note: This rule is enforced automatically by Rubocop.
Using the inline :javascript
Haml filters comes with a
performance overhead. Using inline JavaScript is not a good way to structure your code and should be avoided.
Note: We've removed these two filters in an initializer.
- Stack Overflow: Why you should not write inline JavaScript