New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep your description short #4

Open
andreareginato opened this Issue Oct 3, 2012 · 8 comments

Comments

Projects
None yet
8 participants
@andreareginato
Collaborator

andreareginato commented Oct 3, 2012

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

@nirvdrum

This comment has been minimized.

Show comment
Hide comment
@nirvdrum

nirvdrum Oct 3, 2012

40 characters is totally arbitrary. A description should be as long as it needs to be to convey the information it needs to convey. Be concise, sure. But don't hold yourself to some magical limit, IMHO.

nirvdrum commented Oct 3, 2012

40 characters is totally arbitrary. A description should be as long as it needs to be to convey the information it needs to convey. Be concise, sure. But don't hold yourself to some magical limit, IMHO.

@iain

This comment has been minimized.

Show comment
Hide comment
@iain

iain Oct 5, 2012

Also, be careful with automatic spec descriptions. Consider this spec:

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

its(:owner) { should eq user }

When you run this with the formatter doc, or when the spec fails, the spec name is completely unreadable.

iain commented Oct 5, 2012

Also, be careful with automatic spec descriptions. Consider this spec:

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

its(:owner) { should eq user }

When you run this with the formatter doc, or when the spec fails, the spec name is completely unreadable.

@inancgumus

This comment has been minimized.

Show comment
Hide comment
@inancgumus

inancgumus Nov 9, 2012

I think the output formatter is somewhat verbose. Because, in the example it doesn't matter whether it responses with 422 or not. It should response correctly, that's all matters. Telling about the output values are verbose.

inancgumus commented Nov 9, 2012

I think the output formatter is somewhat verbose. Because, in the example it doesn't matter whether it responses with 422 or not. It should response correctly, that's all matters. Telling about the output values are verbose.

@ZenCocoon

This comment has been minimized.

Show comment
Hide comment
@ZenCocoon

ZenCocoon Jul 24, 2014

I believe the "good" example should use is_expected.to instead of should as mentioned in the section "Expect vs Should syntax"

ZenCocoon commented Jul 24, 2014

I believe the "good" example should use is_expected.to instead of should as mentioned in the section "Expect vs Should syntax"

@dankohn

This comment has been minimized.

Show comment
Hide comment
@dankohn

dankohn Jul 24, 2014

Collaborator

Yes, I fixed this with #115 and it was merged but @andreareginato has been slow pushing the new version to live.

Collaborator

dankohn commented Jul 24, 2014

Yes, I fixed this with #115 and it was merged but @andreareginato has been slow pushing the new version to live.

@ZenCocoon

This comment has been minimized.

Show comment
Hide comment
@ZenCocoon

ZenCocoon Jul 25, 2014

Great news, thanks.

ZenCocoon commented Jul 25, 2014

Great news, thanks.

@mattvanhorn

This comment has been minimized.

Show comment
Hide comment
@mattvanhorn

mattvanhorn Aug 21, 2015

"not valid" conveys a lot less useful information than "has unexpected parameters"
I think it is bad practice to encourage vague specifications.
I shouldn't have to go searching for the subject or setup to find out what "not valid" means.
See also: http://xunitpatterns.com/Obscure%20Test.html#Mystery%20Guest

mattvanhorn commented Aug 21, 2015

"not valid" conveys a lot less useful information than "has unexpected parameters"
I think it is bad practice to encourage vague specifications.
I shouldn't have to go searching for the subject or setup to find out what "not valid" means.
See also: http://xunitpatterns.com/Obscure%20Test.html#Mystery%20Guest

@jmonsanto

This comment has been minimized.

Show comment
Hide comment
@jmonsanto

jmonsanto Feb 9, 2016

IMHO, 40 characters is really limiting -- may even result to much more confusion for the sake of meeting the 40 char limit. Conciseness is key though.

It's better if rephrased like this:

A spec description ideally should never be longer than 40 characters. If this happens you should split it using a context.

jmonsanto commented Feb 9, 2016

IMHO, 40 characters is really limiting -- may even result to much more confusion for the sake of meeting the 40 char limit. Conciseness is key though.

It's better if rephrased like this:

A spec description ideally should never be longer than 40 characters. If this happens you should split it using a context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment