Nabble - RSpec

Re: no should raise_exception

2009-12-22T14:08:49Z

On Tue, Dec 22, 2009 at 9:33 AM, rogerdpack <rogerpack2005@...> wrote:

> raise_error already catches any type of exception, error or not:
>
> class BlahException < Exception; end
> class BlahError < StandardError; end
>
> lambda { raise BlahException }.should raise_error(BlahException)
> lambda { raise BlahError }.should raise_error(BlahError)
> lambda { raise "blah" }.should raise_error(RuntimeError, "blah")

Thanks for the response. I think my request was more of a "why call
them errors--in my head one doesn't raise errors--one raises
exceptions and interprets them as errors, so allowing for the syntax
raise_exception would be more mind friendly to me."

What I really want to say is "should raise(Blah)" but Ruby already defines raise as a keyword :)

I'd be open to aliasing raise_error with raise_exception, renaming it to raise_exception and aliasing raise_error for compatibility, but I think this might just add confusion rather than clarifying intent. Thoughts?

David

-r

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: class variables different between spec and runtime?

2009-12-22T10:51:45Z

DOH!
Thanks David,

Happy Holidays!

Peter Fitzgibbons
(847) 687-7646
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@...

On Tue, Dec 22, 2009 at 9:24 AM, David Chelimsky <dchelimsky@...> wrote:

On Tue, Dec 22, 2009 at 9:22 AM, David Chelimsky <dchelimsky@...> wrote:

On Tue, Dec 22, 2009 at 9:14 AM, Peter Fitzgibbons <peter.fitzgibbons@...> wrote:

Hello Folks,

This gist http://gist.github.com/261791 has an example user.rb, user_spec.rb
At runtime, this snippet fails

u = User.find(123)
u.update_with_profile({...})
The error occurred while evaluating nil.select):
app/models/user.rb:6:in `moderator_fields'
app/models/user.rb:118:in `update_with_profile'

The spec passes all-green.

Could you tell me how this might be ?

The user in the spec comes from new_with_profile(), which sets instance variables on the User class.

The user in the console comes from find(), and those ivars are not yet set.

Also - @params in the User class (in the class methods) is not the same @params in the User instances (in update_with_profile).

HTH,
David

Thanks,

Peter Fitzgibbons
(847) 687-7646
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@...

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: concept of given

2009-12-22T08:34:59Z

On Tue, Dec 22, 2009 at 10:31 AM, rogerdpack <rogerpack2005@...> wrote:

> context "given a certain set of paths" do

Ahh so it's called context.

Cool (though I'll admit that naming it "given" can make it sound more
like an English sentence, so an alias would be a suggestion).

http://gist.github.com/206969

I'm not adding that to rspec though, as we already have enough confusion just between context and describe :)

Cheers,
David

Much thanks.
-r

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: concept of given

2009-12-22T08:31:04Z

> context "given a certain set of paths" do

Ahh so it's called context.

Cool (though I'll admit that naming it "given" can make it sound more
like an English sentence, so an alias would be a suggestion).

Much thanks.
-r
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: concept of given

2009-12-22T08:19:08Z

On Tue, Dec 22, 2009 at 10:15 AM, Rick DeNatale <rick.denatale@...> wrote:

On Tue, Dec 22, 2009 at 10:38 AM, David Chelimsky <dchelimsky@...> wrote:
> On Tue, Dec 22, 2009 at 9:35 AM, rogerdpack <rogerpack2005@...> wrote:
>>
>> Forgive me if the question is a common one...
>>
>> does rspec have any concept like
>>
>> given "a certain set of paths" do
>>
>> it "should be able to recreate them" do; end
>> it "..."; end
>> end
>
> Not built into rspec. There is a merb extension that does that, but there is
> no "when" and "then" counterpart, so I didn't want to add it to rspec.

It looks like that merb extension was about injecting a part of a
before block by adding an option to describe, yes?
http://www.mail-archive.com/rspec-users@.../msg07327.html

I don't see that that's what Roger is asking for though. It seems to
me that he's asking more for yet another synonym for describe or
context.

In which case I'd suggest just using describe or context as in:

context "given a certain set of paths" do
before(:each) do
# code to set up the paths however the included specs need them, e.g.
@paths = ["a/b", "c/d"]
end

it "should be able to recreate them" do; end
it "..."; end
end

I tend to use describe for the top level, and context when nested.

Ah - I see what you mean. Though, I tend to use describe() for nouns and context for context.

describe "something" do

context "in some state" do

Usuall that works out that the outer block starts w/ describe and the inner starts w/ context, but sometimes there are describe blocks nested within describe blocks as well.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: concept of given

2009-12-22T08:15:53Z

On Tue, Dec 22, 2009 at 10:38 AM, David Chelimsky <dchelimsky@...> wrote:

> On Tue, Dec 22, 2009 at 9:35 AM, rogerdpack <rogerpack2005@...> wrote:
>>
>> Forgive me if the question is a common one...
>>
>> does rspec have any concept like
>>
>> given "a certain set of paths" do
>>
>> it "should be able to recreate them" do; end
>> it "..."; end
>> end
>
> Not built into rspec. There is a merb extension that does that, but there is
> no "when" and "then" counterpart, so I didn't want to add it to rspec.

It looks like that merb extension was about injecting a part of a
before block by adding an option to describe, yes?
http://www.mail-archive.com/rspec-users@.../msg07327.html

I don't see that that's what Roger is asking for though. It seems to
me that he's asking more for yet another synonym for describe or
context.

In which case I'd suggest just using describe or context as in:

context "given a certain set of paths" do
before(:each) do
# code to set up the paths however the included specs need them, e.g.
@paths = ["a/b", "c/d"]
end

it "should be able to recreate them" do; end
it "..."; end
end

I tend to use describe for the top level, and context when nested.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: concept of given

2009-12-22T07:38:12Z

On Tue, Dec 22, 2009 at 9:35 AM, rogerdpack <rogerpack2005@...> wrote:

Forgive me if the question is a common one...

does rspec have any concept like

given "a certain set of paths" do

it "should be able to recreate them" do; end
it "..."; end
end

Not built into rspec. There is a merb extension that does that, but there is no "when" and "then" counterpart, so I didn't want to add it to rspec.

HTH,
David

?
Thanks.
-r
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: class variables different between spec and runtime?

2009-12-22T07:36:01Z

On Tue, Dec 22, 2009 at 9:30 AM, Rick DeNatale <rick.denatale@...> wrote:

Also counting on class variables to retain state in Rails is a recipe
for disaster.

Did you read that in rails recipes?

:-/

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

concept of given

2009-12-22T07:35:18Z

Forgive me if the question is a common one...

does rspec have any concept like

given "a certain set of paths" do

it "should be able to recreate them" do; end
it "..."; end
end

?
Thanks.
-r
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: no should raise_exception

2009-12-22T07:33:30Z

> raise_error already catches any type of exception, error or not:
>
> class BlahException < Exception; end
> class BlahError < StandardError; end
>
> lambda { raise BlahException }.should raise_error(BlahException)
> lambda { raise BlahError }.should raise_error(BlahError)
> lambda { raise "blah" }.should raise_error(RuntimeError, "blah")

Thanks for the response. I think my request was more of a "why call
them errors--in my head one doesn't raise errors--one raises
exceptions and interprets them as errors, so allowing for the syntax
raise_exception would be more mind friendly to me."

-r
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: class variables different between spec and runtime?

2009-12-22T07:30:41Z

On Tue, Dec 22, 2009 at 10:24 AM, David Chelimsky <dchelimsky@...> wrote:

>
>
> On Tue, Dec 22, 2009 at 9:22 AM, David Chelimsky <dchelimsky@...>
> wrote:
>>
>>
>> On Tue, Dec 22, 2009 at 9:14 AM, Peter Fitzgibbons
>> <peter.fitzgibbons@...> wrote:
>>>
>>> Hello Folks,
>>>
>>> This gist http://gist.github.com/261791 has an example user.rb,
>>> user_spec.rb
>>> At runtime, this snippet fails
>>>
>>> u = User.find(123)
>>> u.update_with_profile({...})
>>> The error occurred while evaluating nil.select):
>>> app/models/user.rb:6:in `moderator_fields'
>>> app/models/user.rb:118:in `update_with_profile'
>>>
>>> The spec passes all-green.
>>>
>>> Could you tell me how this might be ?
>>
>> The user in the spec comes from new_with_profile(), which sets instance
>> variables on the User class.
>> The user in the console comes from find(), and those ivars are not yet
>> set.
>
> Also - @params in the User class (in the class methods) is not the same
> @params in the User instances (in update_with_profile).
> HTH,
> David

Also counting on class variables to retain state in Rails is a recipe
for disaster.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: class variables different between spec and runtime?

2009-12-22T07:24:33Z

On Tue, Dec 22, 2009 at 9:22 AM, David Chelimsky <dchelimsky@...> wrote:

On Tue, Dec 22, 2009 at 9:14 AM, Peter Fitzgibbons <peter.fitzgibbons@...> wrote:

Hello Folks,

This gist http://gist.github.com/261791 has an example user.rb, user_spec.rb
At runtime, this snippet fails

u = User.find(123)
u.update_with_profile({...})
The error occurred while evaluating nil.select):
app/models/user.rb:6:in `moderator_fields'
app/models/user.rb:118:in `update_with_profile'

The spec passes all-green.

Could you tell me how this might be ?

The user in the spec comes from new_with_profile(), which sets instance variables on the User class.

The user in the console comes from find(), and those ivars are not yet set.

Also - @params in the User class (in the class methods) is not the same @params in the User instances (in update_with_profile).

HTH,
David

Thanks,

Peter Fitzgibbons
(847) 687-7646
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@...

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: class variables different between spec and runtime?

2009-12-22T07:22:15Z

On Tue, Dec 22, 2009 at 9:14 AM, Peter Fitzgibbons <peter.fitzgibbons@...> wrote:

Hello Folks,

This gist http://gist.github.com/261791 has an example user.rb, user_spec.rb
At runtime, this snippet fails

u = User.find(123)
u.update_with_profile({...})
The error occurred while evaluating nil.select):
app/models/user.rb:6:in `moderator_fields'
app/models/user.rb:118:in `update_with_profile'

The spec passes all-green.

Could you tell me how this might be ?

The user in the spec comes from new_with_profile(), which sets instance variables on the User class.

The user in the console comes from find(), and those ivars are not yet set.

Thanks,

Peter Fitzgibbons
(847) 687-7646
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@...

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

class variables different between spec and runtime?

2009-12-22T07:14:28Z

Hello Folks,

This gist http://gist.github.com/261791 has an example user.rb, user_spec.rb
At runtime, this snippet fails

u = User.find(123)
u.update_with_profile({...})
The error occurred while evaluating nil.select):
app/models/user.rb:6:in `moderator_fields'
app/models/user.rb:118:in `update_with_profile'

The spec passes all-green.

Could you tell me how this might be ?

Thanks,

Peter Fitzgibbons
(847) 687-7646
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM AOL: peter.fitzgibbons@...

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: spec with user culture

2009-12-22T06:33:32Z

On Tue, Dec 22, 2009 at 8:25 AM, Gnagno Gnagno <lists@...> wrote:

Tom Stuart wrote:
> How does the application detect the user's "culture"?
>
> Cheers,
> -Tom

Thanks for your reply Tom,

in my home controller I have a line like this for each language:
redirect_to localized_home_page_path :culture => 'es' and return if
request.env['HTTP_ACCEPT_LANGUAGE'].include? 'es-ES'

You can set that explicitly in the example:

it "should redirect to spanish home page" do

  request.env['HTTP_ACCEPT_LANGUAGE'] = 'es-ES'
  get 'index'
  response.should redirect_to(spanish_home_page)
end

HTH,
David

as I said before I am just 'experimenting and playing' so any suggestion
is accepted :)

maybe I should access to the request object from my spec code?

--
Posted via http://www.ruby-forum.com/.
_______________________________________________

rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: spec with user culture

2009-12-22T06:25:12Z

Tom Stuart wrote:
> How does the application detect the user's "culture"?
>
> Cheers,
> -Tom

Thanks for your reply Tom,

in my home controller I have a line like this for each language:
redirect_to localized_home_page_path :culture => 'es' and return if
request.env['HTTP_ACCEPT_LANGUAGE'].include? 'es-ES'

as I said before I am just 'experimenting and playing' so any suggestion
is accepted :)

maybe I should access to the request object from my spec code?

--
Posted via http://www.ruby-forum.com/.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: spec with user culture

2009-12-22T03:41:01Z

On 22 Dec 2009, at 11:26, Gnagno Gnagno wrote:
> it "should redirect to spanish home page" do
> get 'index'
> #don't know how to say the culture is spanish
> response.should redirect_to(spanish_home_page)
> end

How does the application detect the user's "culture"?

Cheers,
-Tom
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

spec with user culture

2009-12-22T03:26:23Z

Hello all,
I am making my first experiments with rspec, I wanted to do something
like this:

when a user visit the home page of my site he will be redirected
depending on his culture, so if his culture is english he will be
redirected to myapp/en if he is italian to myapp/it and so on....

how can I say this with rspec?
I was trying something like:

it "should redirect to spanish home page" do
get 'index'
#don't know how to say the culture is spanish
response.should redirect_to(spanish_home_page)
end

any help?

Thanks
Gnagno
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: no should raise_exception

2009-12-20T10:51:23Z

On Dec 20, 2009, at 6:07 am, Elliot Winkler wrote:

> raise_error already catches any type of exception, error or not:
>
> class BlahException < Exception; end
> class BlahError < StandardError; end
>
> lambda { raise BlahException }.should raise_error(BlahException)
> lambda { raise BlahError }.should raise_error(BlahError)
> lambda { raise "blah" }.should raise_error(RuntimeError, "blah")

Although it would be unusual to catch non-Error Exceptions in most cases? Most indicate unrecoverable failure; only the SignalException looks like something you might want to catch - I don't know, though. I assume you'd normally register a handler for that.

Ashley

--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: no should raise_exception

2009-12-19T22:07:14Z

raise_error already catches any type of exception, error or not:

class BlahException < Exception; end
class BlahError < StandardError; end

lambda { raise BlahException }.should raise_error(BlahException)
lambda { raise BlahError }.should raise_error(BlahError)
lambda { raise "blah" }.should raise_error(RuntimeError, "blah")

-- Elliot

On Sat, Dec 19, 2009 at 11:12 PM, rogerdpack <rogerpack2005@...> wrote:

>
> I know there's a raise_error
> however...exceptions are not always errors, so I had expected a
> raise_exception matcher...would this be a reasonable addition (I'd be
> happy to do it).
> Thanks.
> -r
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

no should raise_exception

2009-12-19T21:12:48Z

I know there's a raise_error
however...exceptions are not always errors, so I had expected a
raise_exception matcher...would this be a reasonable addition (I'd be
happy to do it).
Thanks.
-r
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: State-based expectations (as per jMock in GOOS)

2009-12-19T17:54:05Z

On 18 Dec 2009, at 14:46, Tom Stuart wrote:

> Can you elaborate? From a position of no knowledge, the most obvious question to me is: why would I care about the state of O? Either the change in O's state is observable through its behaviour (in which case I specify that behaviour) or it's not (in which case I don't care).

On further investigation (aka reading up to chapter 24) it's apparent that this state-based testing is effectively a flexible form of message expectation ordering. What's clever is that it gives an intermediate level between no ordering and sequential ordering. It's like ordering "sets" of expectations, at least that's how it appears to me at first glance.

Worth more investigation, I think...

Ashley

--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: State-based expectations (as per jMock in GOOS)

2009-12-18T07:15:59Z

On Dec 18, 2009, at 2:46 pm, Tom Stuart wrote:

> Can you elaborate? From a position of no knowledge, the most obvious question to me is: why would I care about the state of O? Either the change in O's state is observable through its behaviour (in which case I specify that behaviour) or it's not (in which case I don't care).

The example given is for an auction sniper (S). So,

Given S has just notified one of its listeners that it's bidding
When S is informed that a bid has been made by a competitor
And the auction is closed
Then S should notify its listeners that it lost the auction

Given S has just notified one of its listeners that it's bidding
When S is informed that its bid is highest
And the auction is closed
Then S should notify its listeners that it won the auction

The last one looks like the code below in Java[1], but note this is further on from the code in chapter 14.

Interestingly, writing it as GWT transforms the style of the expectations. eg,

"When S is informed that a bid has been made by a competitor"

replaces (something like)

Allow S to notify its listeners that it's in the bidding state

Am I making sense? Not sure if these examples capture the essense.

Ashley

@Test public void
reportsWonIfAuctionClosesWhenWinning() {
allowingSniperBidding();
allowingSniperWinning();
ignoringAuction();

context.checking(new Expectations() {{
atLeast(1).of(sniperListener).sniperStateChanged(
new SniperSnapshot(ITEM_ID, 135, 135, WON));
when(sniperState.is("winning"));
}});

sniper.currentPrice(123, 12, PriceSource.FromOtherBidder);
sniper.currentPrice(135, 45, PriceSource.FromSniper);
sniper.auctionClosed();
}

private void allowingSniperBidding() {
allowSniperStateChange(BIDDING, "bidding");
}

private void allowingSniperWinning() {
allowSniperStateChange(WINNING, "winning");
}

private void allowSniperStateChange(final SniperState newState, final String oldState) {
context.checking(new Expectations() {{
allowing(sniperListener).sniperStateChanged(with(aSniperThatIs(newState))); then(sniperState.is(oldState));
}});
}

[1] http://github.com/sf105/goos-code/blob/master/test/unit/test/auctionsniper/AuctionSniperTest.java

--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: State-based expectations (as per jMock in GOOS)

2009-12-18T06:46:50Z

On 18 Dec 2009, at 14:35, Ashley Moran wrote:
> The principle appears to be
> object O has sent message M => O is in state S
> followed by
> O is in state S => (expectation E met) passes spec
> O is not in state S => (expectation E met) violates spec

Can you elaborate? From a position of no knowledge, the most obvious question to me is: why would I care about the state of O? Either the change in O's state is observable through its behaviour (in which case I specify that behaviour) or it's not (in which case I don't care).

Cheers,
-Tom
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

State-based expectations (as per jMock in GOOS)

2009-12-18T06:35:55Z

Hi all

I'm working my way through Growing Object-Oriented Software[1], currently at the start of chapter 15. Chapter 14 introduces a concept I haven't seen before, state-based expectations based on sent messages.

The principle appears to be

object O has sent message M => O is in state S

followed by

O is in state S => (expectation E met) passes spec
O is not in state S => (expectation E met) violates spec

Has anyone tried this with RSpec (mocks) yet? Just wondered if it was doable with the current syntax support or would need an extension.

I thought I'd fire this off now to get ideas, as I won't be coding using this technique until I've finished the book (a week at least, I imagine).

Cheers
Ashley

[1] http://www.amazon.co.uk/gp/product/0321503627/

--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: spec'ing controllers

2009-12-16T09:33:56Z

http://archive.patmaddox.com/blog/2009/1/15/how-i-test-controllers-2009-remix is my take on things. Due for an update though looks like :)

On Dec 16, 2009, at 8:56 AM, Stefan Kanev wrote:

Hey guys.

I switched completely to RSpec and Cucumber this spring and I am really happy with. While I think I've gotten quite good with it, I'm not sure I understand the value of spec'ing controllers (in Rails). I would appreciate if you can give me some suggestions. Let me elaborate:

The RSpec book suggests mocking models and not integrating vies controller specs. Following that, I usually end up with something like this: http://gist.github.com/257946

I see a few benefits:
It helps keeping the controllers simple. For example, while writing that spec I discovered that Topic should have #update_topic_hits (as opposed to inlining it there). That improved the design.

When mocking gets tricky, I treat this as a code smell and start refactoring. Usually it works out well.
Specs are faster. Remembering how much time it took to run the functional tests on an old project, I can really appreciate that.

Small changes in models (or views) don't result in broken controller specs. It took some time, but I can see it now.
However, I still don't feel too confident about the way I'm doing it. Some of my worries:

It feels like lots and lots of code. I'm normally at 2:1 test:code, but it feels I'm overdoing it. *feels* is the key word here -- I might be worrying too much.
I have a similar spec for each RESTful controller. Looks like duplication, but I'm not sure what to do about it

Often the specs are passing when the code is broken (due to the mocks). While Cucumber catches those errors for me, I'm not sure if they shouldn't be in the specs in some way.
It's a lot of effort. Eventually ones gets used to it, but I can't decide whether it pays of or not.

Can you validate (or invalidate) my reasoning? It will be very nice to hear a comment from more experienced rspec users. Comments on the the spec I posted would be appreciated too, of course.

Thanks very much,
Stefan
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: spec'ing controllers

2009-12-16T09:31:04Z

On 16 Dec 2009, at 16:56, Stefan Kanev wrote:

> Hey guys.
>
> I switched completely to RSpec and Cucumber this spring and I am
> really happy with. While I think I've gotten quite good with it, I'm
> not sure I understand the value of spec'ing controllers (in Rails).
> I would appreciate if you can give me some suggestions. Let me
> elaborate:
>
> The RSpec book suggests mocking models and not integrating vies
> controller specs. Following that, I usually end up with something
> like this: http://gist.github.com/257946
>
> I see a few benefits:
> • It helps keeping the controllers simple. For example, while
> writing that spec I discovered that Topic should have
> #update_topic_hits (as opposed to inlining it there). That improved
> the design.
> • When mocking gets tricky, I treat this as a code smell and start
> refactoring. Usually it works out well.
> • Specs are faster. Remembering how much time it took to run the
> functional tests on an old project, I can really appreciate that.
> • Small changes in models (or views) don't result in broken
> controller specs. It took some time, but I can see it now.
> However, I still don't feel too confident about the way I'm doing
> it. Some of my worries:
> • It feels like lots and lots of code. I'm normally at 2:1
> test:code, but it feels I'm overdoing it. *feels* is the key word
> here -- I might be worrying too much.
> • I have a similar spec for each RESTful controller. Looks like
> duplication, but I'm not sure what to do about it
> • Often the specs are passing when the code is broken (due to the
> mocks). While Cucumber catches those errors for me, I'm not sure if
> they shouldn't be in the specs in some way.
> • It's a lot of effort. Eventually ones gets used to it, but I
> can't decide whether it pays of or not.
> Can you validate (or invalidate) my reasoning? It will be very nice
> to hear a comment from more experienced rspec users. Comments on the
> the spec I posted would be appreciated too, of course.
>
> Thanks very much,
> Stefan

Sounds like you've got it just about right to me :)

I think the excess overhead thing will pass. Partly because you'll get
faster at it, but also partly as your design skill improves (guided by
mocks) you'll feel less need to drive out every single change with a
unit test, and rely a little more on Cucumber. Your observation about
specs passing when mocks are wrong is a common one, and one I remember
struggling with when I first learned TDD, but again as you learn to
trust Cucumber you'll find that this is OK.

cheers,
Matt

+447974 430184
matt@...
http://mattwynne.net

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

spec'ing controllers

2009-12-16T08:56:46Z

Hey guys.

I switched completely to RSpec and Cucumber this spring and I am really happy with. While I think I've gotten quite good with it, I'm not sure I understand the value of spec'ing controllers (in Rails). I would appreciate if you can give me some suggestions. Let me elaborate:

The RSpec book suggests mocking models and not integrating vies controller specs. Following that, I usually end up with something like this: http://gist.github.com/257946

I see a few benefits:

It helps keeping the controllers simple. For example, while writing that spec I discovered that Topic should have #update_topic_hits (as opposed to inlining it there). That improved the design.
When mocking gets tricky, I treat this as a code smell and start refactoring. Usually it works out well.
Specs are faster. Remembering how much time it took to run the functional tests on an old project, I can really appreciate that.
Small changes in models (or views) don't result in broken controller specs. It took some time, but I can see it now.

However, I still don't feel too confident about the way I'm doing it. Some of my worries:

It feels like lots and lots of code. I'm normally at 2:1 test:code, but it feels I'm overdoing it. *feels* is the key word here -- I might be worrying too much.
I have a similar spec for each RESTful controller. Looks like duplication, but I'm not sure what to do about it
Often the specs are passing when the code is broken (due to the mocks). While Cucumber catches those errors for me, I'm not sure if they shouldn't be in the specs in some way.
It's a lot of effort. Eventually ones gets used to it, but I can't decide whether it pays of or not.

Can you validate (or invalidate) my reasoning? It will be very nice to hear a comment from more experienced rspec users. Comments on the the spec I posted would be appreciated too, of course.

Thanks very much,

Stefan

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

cleanup pendings?

2009-12-15T09:05:43Z

Currently with pending...

it "should do something";

or

it "should do something" do
pending "some work"
end

I get this type of output:

Pending:

After should immediately return if the other process doesn't exist
(Not Yet Implemented)
C:/dev/ruby/wait_for/test/spec.after.rb:5:in `block in <top (required)
>'

that part in block in <top (required)> is a bit confusing to me.
Anyway to get rid of that, or what is going on?

Thanks!
-r
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: "have" matcher special case for owned collection with 1 item

2009-12-14T21:59:55Z

On Mon, Dec 14, 2009 at 3:57 PM, DeNigris Sean <sean@...> wrote:
> If I'm reading the docs right, the current implementation would be: my_workspace.should have(1).documents
>
> Would it be hard to have it be: my_workspace.should have(1).document
> ^
> (no s)

Should be pretty simple. Why don't you file a feature request at
http://rspec.lighthouseapp.com? If you submit a patch w/ specs it'll
likely get in sooner than later.

> Sean DeNigris
> sean@...
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

"have" matcher special case for owned collection with 1 item

2009-12-14T13:57:36Z

If I'm reading the docs right, the current implementation would be: my_workspace.should have(1).documents

Would it be hard to have it be: my_workspace.should have(1).document
^
(no s)
Sean DeNigris
sean@...

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: RSPEC and RoR undefined method for hash when running model tests

2009-12-14T13:50:04Z

Yup, I did.

Thanks all. (unless anyone has any comments on the constants question I just asked in a previous post?)

Regards

Matt

2009/12/14 Tom Stuart <tom@...>

On 14 Dec 2009, at 21:28, Matt Riches wrote:
> describe Address do
> #Test Fixture - Before Each test Create a Standard Bread with the following attributes and properties
> before(:each) do
> @address = {
> :business_name => 'business', :first_line => '10, This Street', :second_line=> 'erewhon', :town=> 'town', :county=>'county',
> :postcode =>'AB12 3CD', :user_id => 1, :lat=>1.01, :lng=>2.02, :status=>Address::JUST_REGISTERED, :route_id=>1
> }
> end
>
> it "should have a status of deleted after reset" do
> @address.reset
> @address.status.should == :Address::DELETED
> end
> end

The problem is that you're setting @address to a hash, not an instance of Address. Did you mean @address = Address.new :business_name => ...?

Cheers,
-Tom
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: RSPEC and RoR undefined method for hash when running model tests

2009-12-14T13:48:49Z

I am still learning, and its been along and frustrating day, but thanks !

Sometimes a fresh (more experienced pair of eyes) can spot the blindingly obvious :)

ok, one more quick question, and its slightly more general and then Im going home for the day.

When I run my tests now I get a series of lines

warning: already initialised constant JUST_REGISTERED

warning: already initialised constant DELETED

etc.

as its only a warning I am not too bothered, but ideally I'd like to stop it if I can. Is this an artefact of me creating constants in the class, then it being called before(:each) ? Is there some way of supressing the warnings, or making the constants only get assigned once? (Maybe another class that just implements the constants?)

Regards

Matt

2009/12/14 Vishu Ramanathan <vishu@...>

This should have been the giveaway

undefined method 'status' for #<Hash...>

In your before you're assigning @address to the parameters, not to a new address

@address = {:foo => 'bar'}

instead of

@address = Address.new({:foo => 'bar'})

-V

On Mon, Dec 14, 2009 at 3:28 PM, Matt Riches <mattriches@...> wrote:

Fair point, thought you could also assume that the omissions are down to my newness at RSpec and RoR :-)

The whole of the code is rather large, I am being asked to retrofit rspec onto the code base as things are changed, so I am only showing what I think are the relevent things..

Code Section

class Address < ActiveRecord::Base



  #Status Codes as Constants
  JUST_REGISTERED = 0

  DELETED = 1

  DECLINED = 2

  APPROVED = 3


def status

  DELETED
end

  def reset    

    #We don't actually delete the record
    #Instead a status field is set

    #And all the data is blanked for data protection reasons

    self.status = DELETED

    self.business_name = ''

    self.first_line = ''

    self.second_line = ''

    self.town = ''

    self.county = ''

    self.postcode = ''

    #MR - added in the following fields
    self.lat = 0.0

    self.lng = 0.0

    self.route_id = 0

    self.save
  end
#.. other code elided

end

RSpec

require 'spec_helper'


describe Address do

  #Test Fixture - Before Each test Create a Standard Bread with the following attributes and properties
  before(:each) do

    @address = {

      :business_name => 'business', :first_line => '10, This Street', :second_line=> 'erewhon', :town=> 'town', :county=>'county',



      :postcode =>'AB12 3CD', :user_id => 1, :lat=>1.01, :lng=>2.02, :status=>Address::JUST_REGISTERED, :route_id=>1



    }
  end


  it "should have a status of deleted after reset" do


    @address.reset

    @address.status.should == :Address::DELETED

  end


end

Thanks David as well, but Tom was right, it was my typing that caused that issue.

Regards

Matt

2009/12/14 Tom Stuart <tom@...>

On 14 Dec 2009, at 20:36, Matt Riches wrote:

> 1) Why are my methods undefined, when they are there (I can create the object via script/console and call the status and reset methods and see them work)
> 2) What is the best way of resolving the issue

You'd be much better off using pastie.org to show us the real code that's having the problem, because your example contains all sorts of omissions and typos (which is likely to be the sort of thing that causes your problem!) and it's impossible to tell how much of it is wrong in the original code versus how much was introduced by you rewriting it as an example.

Cheers,
-Tom
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

--
Vishu Ramanathan
co-founder thinklink llc 312.436.1627
new homepage! ---> thinklinkllc.com
mocklinkr.com makes web mockups come to life
thinklinkr.com is the web-based collaborative outliner

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: RSPEC and RoR undefined method for hash when running model tests

2009-12-14T13:39:22Z

On 14 Dec 2009, at 21:28, Matt Riches wrote:

> describe Address do
> #Test Fixture - Before Each test Create a Standard Bread with the following attributes and properties
> before(:each) do
> @address = {
> :business_name => 'business', :first_line => '10, This Street', :second_line=> 'erewhon', :town=> 'town', :county=>'county',
> :postcode =>'AB12 3CD', :user_id => 1, :lat=>1.01, :lng=>2.02, :status=>Address::JUST_REGISTERED, :route_id=>1
> }
> end
>
> it "should have a status of deleted after reset" do
> @address.reset
> @address.status.should == :Address::DELETED
> end
> end

The problem is that you're setting @address to a hash, not an instance of Address. Did you mean @address = Address.new :business_name => ...?

Cheers,
-Tom
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users

Re: RSPEC and RoR undefined method for hash when running model tests

2009-12-14T13:33:06Z

This should have been the giveaway

undefined method 'status' for #<Hash...>

In your before you're assigning @address to the parameters, not to a new address

@address = {:foo => 'bar'}

instead of

@address = Address.new({:foo => 'bar'})

-V

On Mon, Dec 14, 2009 at 3:28 PM, Matt Riches <mattriches@...> wrote:

Code Section

class Address < ActiveRecord::Base



  #Status Codes as Constants
  JUST_REGISTERED = 0

  DELETED = 1

  DECLINED = 2

  APPROVED = 3


def status

  DELETED
end

  def reset    

    #We don't actually delete the record
    #Instead a status field is set

    #And all the data is blanked for data protection reasons

    self.status = DELETED

    self.business_name = ''

    self.first_line = ''

    self.second_line = ''

    self.town = ''

    self.county = ''

    self.postcode = ''

    #MR - added in the following fields
    self.lat = 0.0

    self.lng = 0.0

    self.route_id = 0

    self.save
  end
#.. other code elided

end

RSpec

require 'spec_helper'


describe Address do

  #Test Fixture - Before Each test Create a Standard Bread with the following attributes and properties
  before(:each) do

    @address = {

      :business_name => 'business', :first_line => '10, This Street', :second_line=> 'erewhon', :town=> 'town', :county=>'county',


      :postcode =>'AB12 3CD', :user_id => 1, :lat=>1.01, :lng=>2.02, :status=>Address::JUST_REGISTERED, :route_id=>1


    }
  end


  it "should have a status of deleted after reset" do


    @address.reset

    @address.status.should == :Address::DELETED

  end


end

Thanks David as well, but Tom was right, it was my typing that caused that issue.

Regards

Matt

2009/12/14 Tom Stuart <tom@...>

On 14 Dec 2009, at 20:36, Matt Riches wrote:

> 1) Why are my methods undefined, when they are there (I can create the object via script/console and call the status and reset methods and see them work)
> 2) What is the best way of resolving the issue

You'd be much better off using pastie.org to show us the real code that's having the problem, because your example contains all sorts of omissions and typos (which is likely to be the sort of thing that causes your problem!) and it's impossible to tell how much of it is wrong in the original code versus how much was introduced by you rewriting it as an example.

Cheers,
-Tom
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

From forum: rspec-users