Forum: RSpec How to spec accessing a constant

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick Hoffman (Guest)
on 2008-10-15 22:32
(Received via mailing list)
Hi guys. One of my methods uses a constant in another method, like this:

class A
     def something
         "foo: #{B::BAR}"
     end
end

When writing the spec for A#something , how would you mock or stub
#{B::BAR}, and how would you set an expectation that B::BAR is used?

Thanks,
Nick
B14575f0ca69f10938fdd67e7156e0e1?d=identicon&s=25 Craig Demyanovich (Guest)
on 2008-10-15 22:39
(Received via mailing list)
Probably, I would just check the outcome of the method instead of
checking
interaction with a constant.

Craig
F86901feca747abbb5c6c020362ef2e7?d=identicon&s=25 Zach Dennis (zdennis)
on 2008-10-15 22:43
(Received via mailing list)
On Wed, Oct 15, 2008 at 4:39 PM, Craig Demyanovich
<cdemyanovich@gmail.com> wrote:
> Probably, I would just check the outcome of the method instead of checking
> interaction with a constant.
>

What he said,

--
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick Hoffman (Guest)
on 2008-10-16 02:52
(Received via mailing list)
On 2008-10-15, at 16:39, Craig Demyanovich wrote:
> Probably, I would just check the outcome of the method instead of
> checking interaction with a constant.
>
> Craig

So you guys wouldn't worry about the spec for class A being coupled to
this constant in class B?
-Nick
B14575f0ca69f10938fdd67e7156e0e1?d=identicon&s=25 Craig Demyanovich (Guest)
on 2008-10-16 03:59
(Received via mailing list)
On Wed, Oct 15, 2008 at 8:47 PM, Nick Hoffman <nick@deadorange.com>
wrote:

> On 2008-10-15, at 16:39, Craig Demyanovich wrote:
>
>> Probably, I would just check the outcome of the method instead of checking
>> interaction with a constant.
>>
>> Craig
>>
>
> So you guys wouldn't worry about the spec for class A being coupled to this
> constant in class B?


Since class A is coupled to class B, the specs for A are also coupled to
class B through class A. Thus, I wouldn't worry about the coupling. Why
does
a method of class A directly access a constant of class B? Does the
constant
belong in class A? Does the method belong in class B? If you can and
want to
be more specific with your code and specs, I'm sure that we can all
write
some specs together.

Regards,
Craig
944f769c99deff7aa8bc3b5b93830b7a?d=identicon&s=25 Scott Taylor (Guest)
on 2008-10-16 07:48
(Received via mailing list)
On Oct 15, 2008, at 4:31 PM, Nick Hoffman wrote:

> #{B::BAR}, and how would you set an expectation that B::BAR is used?
Just hide the constant behind a method, something like this:

class A
def something; "foo :#{bar}"; end
def bar; B::BAR; end
end

This allows you to stub the constant, if need be.

Scott
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick Hoffman (Guest)
on 2008-10-16 17:23
(Received via mailing list)
On 2008-10-15, at 21:59, Craig Demyanovich wrote:
> Since class A is coupled to class B, the specs for A are also
> coupled to class B through class A. Thus, I wouldn't worry about the
> coupling. Why does a method of class A directly access a constant of
> class B? Does the constant belong in class A? Does the method belong
> in class B? If you can and want to be more specific with your code
> and specs, I'm sure that we can all write some specs together.
>
> Regards,
> Craig

Hi Craig. Here're some code snippets:
http://pastie.org/293925

Property#javascript_map_marker_code generates the Javascript code
necessary to:
1) Create a [Google] map marker that represents a property instance.
2) Add the marker to the map.
To perform #2, RentalMap::MAP_NAME must be accessed somehow, be it
directly, or through a method as Scott suggested.

RentalMap::MAP_NAME should definitely be part of the RentalMap model.
It should not be part of the Property model.

Property#javascript_map_marker_code belongs in the Property model,
because it acts upon (IE: uses several attributes of) a Property
instance.

Cheers,
Nick
B14575f0ca69f10938fdd67e7156e0e1?d=identicon&s=25 Craig Demyanovich (Guest)
on 2008-10-16 21:13
(Received via mailing list)
Cool. Having seen something a little more concrete, I like your design
decisions. In this case, I'd go with Scott's recommendation of hiding
the
constant behind a method.

Regards,
Craig
49de4cd2f26705785cbef2b15a9df7aa?d=identicon&s=25 Nick Hoffman (Guest)
on 2008-10-16 23:25
(Received via mailing list)
On 2008-10-16, at 15:12, Craig Demyanovich wrote:
> Cool. Having seen something a little more concrete, I like your
> design decisions. In this case, I'd go with Scott's recommendation
> of hiding the constant behind a method.
>
> Regards,
> Craig

Thanks for taking a look, Craig, and giving me your opinion.

Cheers,
Nick
2ab31489a58f527712d75f36c446a465?d=identicon&s=25 Marcelo de Moraes Serpa (Guest)
on 2010-02-18 19:26
(Received via mailing list)
Why don't you open the class, and set the constant like so:

class TheClass
  CONSTANT = 'value_it_should_have_for_the_current_spec'
end

This worked for me.

Marcelo.
This topic is locked and can not be replied to.