betterspecs / betterspecs Goto Github PK
View Code? Open in Web Editor NEWRSpec Best Practices
Home Page: http://betterspecs.org
RSpec Best Practices
Home Page: http://betterspecs.org
Write your thoughts about the "Test all possible cases" best practice.
Write your thoughts about the "how to describe your methods" best practice.
Write your thoughts about the "faster tests with spork " 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.
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 "use contexts" 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 "mock or not to mock" best practice.
Originated from #153 (comment)
@akz92 -- please coordinate with @benoittgt, as he will be moving the translated pages to the new layout.
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.
I think here link is missed.
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.
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.
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.
master
into (and before) gh-pages
Write your thoughts about the "shared examples" best practice.
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.
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
Write your thoughts about the "create only the data you need" 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).
Write your thoughts about the "useful formatter" best practice.
Originated from #153 (comment)
@benoittgt -- please coordinate with @akz92, as he will be working directly with the translations themselves.
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 :-)
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:
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.
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.
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.
Write your thoughts about the "Easy to read matcher" best practice.
Write your thoughts about the "single expectation test" best practice.
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:
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".
[ ]
Tedious, but change all tabs to spaces in code (huge pet-peeve of mine!)Please place all discussion about the site construction here!
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
Write your thoughts about the "keep your description short" best practice.
Write your thoughts about the "use subject" best practice.
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.
They're largely the same.
Write your thoughts about the "mocking HTTP requests " best practice.
Add translations to different languages.
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).
Self-explanatory. This will also help to close a couple PRs.
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:
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.
Write your thoughts about the "don't use should" best practice.
Write your thoughts about the "test what you see" best practice.
Write your thoughts about the "use let and let!" best practice.
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 factories and not fixtures" best practice.
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)
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.
this issue is for putting together all ideas and people who want to make a good redesign.
(see #20 )
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.