Curtis, hey man, I saw your post in the rspec list archives
(http://rubyforge.org/pipermail/rspec-users/2013-August/021811.html). I use
context with pattern A:
describe UsersController do
describe "POST create" do
it "creates a user" do
...
end
context "with bad data" do
My Question is about ordering of describes / context and the various styles
that people are using that deviate from .
Some context first:
Started TDD when i was a university researcher - as a way to do bug fixes
without regression.
Started using rspec in 2006 on the side and eventually switched o
On Thu, Mar 19, 2009 at 11:20 PM, Stephen Eley wrote:
> 2009/3/19 Rick DeNatale :
> > Even 'should be' is a bit grating. I'm tempted to write a pair of
> matchers
> > like be_truthy and be_falsy, but I was wondering what other RSpec users
> have
> > to say.
>
> should be || should_not be: that i
Stephen Eley wrote:
2009/3/19 Rick DeNatale :
Even 'should be' is a bit grating. I'm tempted to write a pair of matchers
like be_truthy and be_falsy, but I was wondering what other RSpec users have
to say.
should be || should_not be: that is the expectation:
Whether 'tis nobler in the
On Fri, Mar 20, 2009 at 4:56 AM, Joseph Wilk wrote:
> Stephen Eley wrote:
>>
>> 2009/3/19 Rick DeNatale :
>>
>>>
>>> Even 'should be' is a bit grating. I'm tempted to write a pair of
>>> matchers
>>> like be_truthy and be_falsy, but I was wondering what other RSpec users
>>> have
>>> to say.
>>>
On Thu, Mar 19, 2009 at 11:42 PM, David Chelimsky wrote:
>
> what_follows.should be_brilliant
Thank you! Glad I could provide a bit of entertainment.
(And hmmm. Now I'm wondering why Ruby culture doesn't have a
phenomenon like that of Perl culture, where hackers have 'Perl Poetry'
competitions
Stephen Eley wrote:
2009/3/19 Rick DeNatale :
Even 'should be' is a bit grating. I'm tempted to write a pair of matchers
like be_truthy and be_falsy, but I was wondering what other RSpec users have
to say.
should be || should_not be: that is the expectation:
Whether 'tis nobler in the
On Thu, Mar 19, 2009 at 8:42 PM, David Chelimsky wrote:
> On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley wrote:
>> 2009/3/19 Rick DeNatale :
>>> Even 'should be' is a bit grating. I'm tempted to write a pair of matchers
>>> like be_truthy and be_falsy, but I was wondering what other RSpec users
On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley wrote:
> 2009/3/19 Rick DeNatale :
>> Even 'should be' is a bit grating. I'm tempted to write a pair of matchers
>> like be_truthy and be_falsy, but I was wondering what other RSpec users have
>> to say.
>
what_follows.should be_brilliant
> should
2009/3/19 Rick DeNatale :
> Even 'should be' is a bit grating. I'm tempted to write a pair of matchers
> like be_truthy and be_falsy, but I was wondering what other RSpec users have
> to say.
should be || should_not be: that is the expectation:
Whether 'tis nobler in the parser to interpret
The o
I hate should/should_not be and so if I really *have* to do it then I
just throw a !! in the method and get back a real boolean. Not ideal,
but it works.
HOWEVER
Predicate matchers *do* accept args, and in the specific example you
gave, the have matcher comes to the rescue. Check out these exam
2009/3/19 Rick DeNatale :
> I like to avoid over-constraining specifications, so for example of methods
> which return 'boolean' values, I prefer to test either truthiness (anything
> but false or nil), or falsiness (either false or nil).
> This isn't an issue true predicate methods which are of th
I like to avoid over-constraining specifications, so for example of methods
which return 'boolean' values, I prefer to test either truthiness (anything
but false or nil), or falsiness (either false or nil).
This isn't an issue true predicate methods which are of the right form to
use be_whatever (a
13 matches
Mail list logo
