describe '#type_id' do
  before { @resource = FactoryGirl.create :device }
  before { @type     = Type.find resource.type_id }
  ...

I think the @type before-block means to reference @resource, not resource; I think this is a copy-paste error from the "good" example below.

Update that guideline to talk about a mock, using something with

expect(something).to receive

Maybe add another guideline describing if you should use a mock or a stub, explaining when to use:

allow(something).to receive 

or

expect(something).to receive

In the following text Myron says to use this on new projects.

You guys think this is a good section to better specs? I personaly have use this on new projects with configuration to use only new syntax.

Write your thoughts about the "how to describe your methods" best practice.

Write your thoughts about the "mock or not to mock" best practice.

Write your thoughts about the "test what you see" best practice.

Hello!

it could be very engaging/fun for people to answer a quizz based on the questions that you would have in the best practices "database", and compute a score based on their correct results etc, so that people can evaluate themselves and improve over time.

Obviously for this to work, you would have to stick to best practices that are rather universally agreed upon as being the best option, rather than things that are more a matter of taste (and the line is sometimes tricky to trace here).

Write your thoughts about the "don't use should" best practice.

Write your thoughts about the "use factories and not fixtures" best practice.

Write your thoughts about the "keep your description short" best practice.

After the move to v2.0, I merged some PRs into master, not realizing that the bulk of the content is not on the gh-pages branch.

• #165 - "Here a" typo
• Manually merge other PRs into gh-pages branch (not currently selected)
• Change default branch from master to gh-pages (@andreareginato)
  • Add blurb in "Contributing" about new default branch (#174)
  • If we make gh-pages the default, do we even need a "master" branch?
• Merge changes from master into (and before) gh-pages

I think here link is missed.

Add translations to different languages.

I think it is important to still keep current best practices, but label older ones as for RSpec 2. Many teams and online classes still use RSpec2, and it is important to maintain compatibility.

• Clarify whether a best practice is for only RSpec2 or RSpec3
• Update all reference links (#139, #141)
• Replace Spork recommendation with Spring (Rails 4)
• Update gems in project, and recommended gems on site
• Research other best practices site, and include (and attribute) content if needed
• Translate all changes into other languages
• Write guidelines in second-person (#142)
• Banner explaining the use of older Rails/RSpec versions and site maintenance (#141 (comment))

Originated from #153 (comment)

• Use jekyll-multiple-languages-plugin to maintain translations

@akz92 -- please coordinate with @benoittgt, as he will be moving the translated pages to the new layout.

Write your thoughts about the "Easy to read matcher" best practice.

Write your thoughts about the "create only the data you need" best practice.

this issue is for putting together all ideas and people who want to make a good redesign.

(see #20 )

Write your thoughts about the "Test all possible cases" best practice.

Self-explanatory. This will also help to close a couple PRs.

See http://www.satisfice.com/blog/archives/27 for background.

Nearly every one of the recommendations on betterspecs.org or good suggestions in specific contexts, and bad suggestions in other contexts. I'd recommend the term "guideline" instead.

Write your thoughts about the "automatic tests with guard" best practice.

You want your specs to be short and sweet. Sometimes some libs provide custom matchers and helpers that can make your "testing life" easy.

let(:user) { FactoryGirl.build :user }
let(:other_user) { FactoryGirl.create :other_user }

After extending your RSpec.configure block with some methods.

RSpec.configure do
  config.include FactoryGirl::Syntax::Methods
  ...
end

You can just write.

let(:user) { build :user }
let(:other_user) { create :other_user }

Same goes for Rack::Test::Methods mixin.

Write your thoughts about the "use let and let!" best practice.

I am surfing around and bumped into a stack overflow where two people voiced the opinion that expectations should not be put into a before hook. The expectations should be put into the example. A third person argued the other way because it was dryer.

I bopped over to here to see what your thoughts are and I don't see the topic discussed. Perhaps this is something that could be added: If the same expectation is going to be applied in (all / most) of the examples of a given context, should that expectation be put into a before block (or what I did was put it inside the let block).

It seems that the URL for Continuous Testing: with Ruby, Rails, and JavaScript is pointing to The Cucumber Book: Behaviour-Driven Development for Testers and Developers.

Either the URL should evaluate to http://www.amazon.com/Continuous-Testing-Ruby-Rails-JavaScript/dp/1934356700 or the image cover should be updated to reflect the cover of the correct book.

Write your thoughts about the "single expectation test" best practice.

In the past few weeks, betterspecs has gained some new collaborators to the repository. While everyone on the team is enthusiastic, we have huge plans and need some additional help!

For complete transparency, here is an unordered list of things we would like to accomplish:

• Obtain more collaborators, especially those who can help monitor translations
• Convert the website (now hosted on Heroku) to a Github Page powered by Jekyll (#153)
• Develop a versioning style, and apply it to all translations. EN would be the most current, with all translations attempting to follow.
  • Possibly moving each translation to its own branch or directory within the repository.
  • We want to use version numbers on the individual translations, we we believe it will help keep them in sync with EN (#20, #78)
• Create a blog and newsletter for website and repository updates
• Also see issue #144

Feel free to leave comments on any ideas you may have.

If you are interested in becoming a collaborator, please email @andreareginato (see profile), as he is the owner of this repository.

I know licensing can be a touchy issue, so I hope I don't offend anyone. Currently the LICENSE.md file contains a simple copyright notice. If no other license is granted, then I can't legally make a copy of this project or modify it for my own use. Ideally I would like to fork this project and use it as part of the standards in my group. I would like to modify it to apply to our group's standards. One of the CC licenses would be nice. It appears that this is intended to be allowed (as the project has already been forked 42 times), but if I'm wrong feel free to ignore this.

Hi,

I was wondering what is the best practice for mocks expectations:

Instead of:

it 'will receive create' do
    VendorSchedulable.should_receive(:create).with(:some, :other)
    CreateVendorSchedule.create(:some, :other)
end

I am wirting

before do
  VendorSchedulable.stub(:create)
  CreateVendorSchedule.create(42, 'deal-43')
end

it { expect(VendorSchedulable).to have_received(:create) }

But I don't really like it { expect

BetterSpecs seems to be intended as a community effort, but many the explanations use the word 'I' since the were originally written by @andreareginato.

I believe this discourages others from contributing updates advice. I would suggest taking an approach similar to the Ruby Style Guide, where the guidance is intended to capture the community's collective viewpoint, so is written from a non-personal point of view.

rubocop-rspec (an extension to rubocop) is a tool to check the code style of RSpec files. Maybe you can promote it somewhere on the betterspecs.org page?

Some of the rules of betterspecs.org are already in there, like: "Use let and let!", "Do not use should" or checks for the file name, or to enforce the use of described_class.

If you have new ideas what could be checked with this tool let me know.

In order that capture related spec, I suggest put a topic about random specs.
I saw a lot of projects not using (and disabling this option from rspec)

They're largely the same.

Write your thoughts about the "use subject" best practice.

Best practice is a term used in betterspecs. Practices are dependent on context. There can be multiple conflicting but good practices with no clear winner. Best practice misses this nuance unfortunately. Best practice discourages independent and critical thought of the practices presented which is an unintended consequence.

Write your thoughts about the "faster tests with spork " best practice.

• Factorygirl tips
• Shared example variables
• Do't make my code more testable

I finished translating betterspecs to russian language, and now I am sure, that it will be very hard to support the whole app in future. Here is the list of things that I think will improve the awesomness of betterspecs.org:

• Layout must be DRY and reusable.
• Menu items must be auto-generated from headers instead of being inserted manualy.
• Same with social buttons.
• Same with additional info links.
• Translations should be more maintanable. It will be great if the translation maintainer could receive a letter when some practice was added or changed in original version of the betterspecs.
• Practices should be voted and discussed on the site, not on the github.

In other words, we should start saving data to the DB and write some ruby code to do it more usable. What do you think?

Thanks.

Originated from #153 (comment)

• Adapt all "translation pages" to the new layout (priority)
• Place all translation pages in a more structured way, while maintaining today's paths

@benoittgt -- please coordinate with @akz92, as he will be working directly with the translations themselves.

E.g. if someone's never used context before, they will want to see other examples of how it's used. I imagine in most cases this will link to the RDoc and/or Relish pages.

Previous participants: @andreareginato , @akz92

As discussed in issue #146, we want to move away from Heroku and instead host the site on Github. Some advantages include:

• Quicker deployment
• Free site hosting (by Github)
• Built-in Markdown support when using Jekyll
• Little to no required downtime
• No need to give collaborators access to an additional service (Heroku)
• Others can easily test their pull requests by calling: jekyll serve -h 0.0.0.0 -p 4000

To see a current live demo of the beta site: https://github.com/akz92/akz92.github.io

Checklist of features for demo site:

• [x] Syntax highlighting (Ruby)
• [x] Mobile-friendly website (akz92/akz92.github.io#1)
• [ ] Disqus compatibility (hopefully deprecating Github issues as "thoughts".
  • Open to other discussion platforms that possibly recognize Markdown.
• [ ] Tedious, but change all tabs to spaces in code (huge pet-peeve of mine!)

Please place all discussion about the site construction here!

Hello, @andreareginato. I would like to know your opinion.

Let's say we have this code:

class Dog
  attr_reader :gender
  attr_accessor :name

  def initialize(gender: gender)
    @gender = gender
  end
end

And the spec might look like this:

describe Dog do
  describe '#gender' do
    it 'provides reading of a gender' do
      dog = Dog.new(gender: 'male')
      expect(dog.gender).to eq('male')
    end
  end

  describe '#name' do
    it 'provides writing and reading of a name' do
      dog = Dog.new(gender: 'female')

      dog.name = 'Stella'

      expect(dog.name).to eq('Stella')
    end
  end
end

What do you think about descriptions? How would you test such code?

Write your thoughts about the "useful formatter" best practice.

Write your thoughts about the "mocking HTTP requests " best practice.

Write your thoughts about the "shared examples" best practice.

On the top menu (probably on the right) we need to insert the capability to choose different languages for better specs. Rght now we have korean and russian translations.

Hello,

adding '{ rspec best practices with ruby }' (with or without braces) to the html title tag let people who manage his visited sites searchng the browser address bar (like me) to write 'rspec best practices' in the bar and find your site if they visited it before.

Moreover, it will increase the rank of the site in the google search 'rspec best practices'.

Per dirtela in una lingua comune: io non uso i segnalibri, trovo che la ricerca nella cronologia della barra degli indirizzi del browser sia più veloce e comoda. Per cui mi piacerebbe che scrivendo 'rspec best practices' nella barra degli indirizzi mi apparisse il tuo sito, che invece non appare dato che la ricerca nella barra degli indirizzi cerca nell'URL e nell'html tag title - almeno, quella di Firefox fa così, le altre non so.

Tra l'altro, anche cercando su Google 'rspec best practices' non riesco a trovae il tuo sito.

In sostanza me l'ero perso; per fortuna ero arrivato al tuo sito tramite Hacker News, per cui scrivendo nell'URL 'rspec best practices' mi ha tirato fuori la segnalazione di Hacker News relativa al sito.

Ah, complimenti per l'idea, proprio bella :-)

describe '#method1' do
  before { expect(SomeClass).to receive(:method2) }
  subject { described_class.new.method1 }

  it 'calls SomeClass.method2' do
    subject
  end
end

VS

describe '#method1' do
  subject { described_class.new.method1 }

  it 'calls SomeClass.method2' do
    expect(SomeClass).to receive(:method2)
    subject
  end
end

Write your thoughts about the "use contexts" best practice.