I've got some code that I (mostly) inherited. It essentially has a
couple of AR class methods that look for a specific record by id:
class Project < ActiveRecord::Base
class << self
def specific_project
@another_specific_project ||= Project.find(10) if
Project.exists?(10)
end
def another_specific_project
@specific_project ||= Project.find(11) if Project.exists?(11)
end
end
end
Typically, when I've specced this code (or more accurately, code that
uses it), I've stubbed out those methods to return a mocked model.
Lately, I've started using cucumber and adding stories for areas we're
adding features to or finding regressions in. From what I can tell, I
can't stub or mock anything from within cucumber step files. Realizing
that the pattern is a bit of code smell, I feel like I have two
directions I could go:
1. Is there a way to stub out the model to return some fixture-type
records?
2. Does anyone have an idea as to how we could refactor this into a
better pattern? Those 2 "projects" are pretty specific to the
production data and will "never be edited," but it still doesn't make
me comfortable.
I'm not sure how to phrase this better. Let me know what other detail
I can provide to make it more clear what I'm looking for.
thanks,
tim
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
I don't think you're really supposed to mock or stub when using cucumber.
> 2. Does anyone have an idea as to how we could refactor this into a better
> pattern? Those 2 "projects" are pretty specific to the production data and
> will "never be edited," but it still doesn't make me comfortable.
Maybe you could add a column that represents the unique characteristic
of the particular projects. I'd probably end up with:
def internal_project
@internal_project ||= Project.find(:first, :conditions => "internal IS TRUE")
end
def demo_project
@demo_project ||= Project.find(:first, :conditions => "demo IS TRUE")
end
or maybe have one column and let its value change:
def internal_project
@internal_project ||= Project.find(:first, :conditions => "role='internal'")
end
def demo_project
@demo_project ||= Project.find(:first, :conditions => "role='demo'")
end
Pat
As Pat said I would avoid mocking/stubbing, you want your cucumber tests
to cut through all the layers of your app including touching the
database.
As for setting up the data, I tend not to use fixtures (I only want to
have the data created for certain tests). Instead I save the relevant
models in the Given steps, preparing for the feature test. If you are
going to repeat the given steps a lot I would extract the model set-up
into a ruby function and reuse this.
--
Joseph Wilk
http://www.joesniff.co.uk
--
Posted via http://www.ruby-forum.com/.
You might also take a look at http://github.com/flogic/object_daddy.
Cheers,
David
I second that.
Aslak
If those objects are built into your system and will never, ever
change, I would consider storing their definition in the code rather
than in the database anyway.
http://www.refactoring.com/catalog/replaceTypeCodeWithSubclasses.html
That would get around your issues with the pristine test database
being different to the production / development database, and IMO
more clearly communicates to future developers that these objects are
'special'.
Of course it depends on how many of them there are, whether you have
a use case for editing them etc, but it's worth thinking about.
Alternatively you could call the migrations that insert this stock
data (presumably you have some) from your spec pre-requisites.
cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com
In case you wondered: The opinions expressed in this email are my own
and do not necessarily reflect the views of any former, current or
future employers of mine.
Thanks all for the ideas. I knew that stubbing or mocking from within
Cucumber was the wrong direction. I started exploring going that
direction, but all my instincts were crying out against it.
I'm going to look into either subclassing the Project model or putting
the differences in the database itself. I've considered putting the
differences into the data previously, but we're talking about 2
distinct projects out of 100+. I would need 2 new columns for the data
and they would only ever each be used for 1 project - doesn't feel
right somehow.
Matt - in terms of subclassing it, I have the entire stable of
projects, 1 "internal" project and 1 "slush fund" project. If I'm
subclassing the project, I assume that I still need to have a record
for them in the database that needs to be findable. So while the
subclass suggestion helps, I'm not sure it gets me all the way there?
Could very well be that I'm missing something there...
>> As for setting up the data, I tend not to use fixtures (I only want
>> to
>> have the data created for certain tests). Instead I save the relevant
>> models in the Given steps, preparing for the feature test. If you are
>> going to repeat the given steps a lot I would extract the model set-
>> up
>> into a ruby function and reuse this.
>
> You might also take a look at http://github.com/flogic/object_daddy.
For test data, I've been using the FixtureReplacement plugin rather
than fixtures - it basically abstracts the creation and destruction of
objects for every scenario. However, I've only been using it for about
a week now. It works well, but I'm not married to it yet by any
stretch. Is Object Daddy in a stable state? it looks pretty tasty, I
have to say.
thanks again,
tim
> Matt - in terms of subclassing it, I have the entire stable of
> projects, 1 "internal" project and 1 "slush fund" project. If I'm
> subclassing the project, I assume that I still need to have a
> record for them in the database that needs to be findable. So while
> the subclass suggestion helps, I'm not sure it gets me all the way
> there? Could very well be that I'm missing something there...
Yeah this is where ActiveRecord's tight coupling to databases really
starts to bite. You *could* override all the Project.find calls and
merge in the two stock, hard-coded projects (not subclasses) into
every resultset but that sounds like quite hard work.
You could also use STI maybe, and store a row for the two stock
projects but only store the type and put everything else in code. If
you only want one of each though, I don't think that refactoring to
subclasses is really appropriate. You more want to be able to call
Project.internal or Project.slush_fund and always get back that
singleton instance of Project...
I've never needed to do this yet in ruby / rails so you may notice
I'm becoming rather hand-wavey at this point. I think I'll get my
coat...
cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com
In case you wondered: The opinions expressed in this email are my own
and do not necessarily reflect the views of any former, current or
future employers of mine.
_______________________________________________
> Hey all,
>
> I've got some code that I (mostly) inherited. It essentially has a
> couple of AR class methods that look for a specific record by id:
>
> class Project < ActiveRecord::Base
> class << self
> def specific_project
> @another_specific_project ||= Project.find(10) if
> Project.exists?(10)
> end
>
> def another_specific_project
> @specific_project ||= Project.find(11) if Project.exists?(11)
> end
> end
> end
Why don't use just use a slug for these things? In other words - use a
unique name for each record, since the numbers 10 and 11 don't mean
much to anyone.
Then, use a factory (like FixtureReplacement or Object Daddy) to
generate the records in env.rb. Here's how you'd do that with
FixtureReplacement (at the bottom of your env.rb file):
include FixtureReplacement
create_project(:slug => "my-unique-name-for-project1")
create_project(:slug => "my-unique-name-for-the-second-project")
Scott
Yah - I actually did a similar thing for another model I found with
the same issue. This way I only have to add one column to the db. For
now, those are the only 2 projects we would need a slug for but, if we
needed more, we could add them later.
thanks for the logical conclusion to my issue :)
> I don't think you're really supposed to mock or stub when using
> cucumber.
We need to stub time in some of our scenarios, which exist to to
verify behavior over time. We're looking into a before/after to
support mocking/stubbing for this scenario.
Cheers,
Luke
--
Luke Melia
lu...@lukemelia.com
http://www.lukemelia.com/
There's no direct hooks into the mock framework and I don't think
there should be, but you can roll your own in the supplied
Before/After methods:
Before do
#do some magic w/ time
end
After do
#undo some magic w/ time
end
Those run before and after every scenario.
> On Tue, Sep 30, 2008 at 9:55 AM, Luke Melia <lu...@lukemelia.com>
> wrote:
>> On Sep 15, 2008, at 4:35 PM, Pat Maddox wrote:
>>
>>> I don't think you're really supposed to mock or stub when using
>>> cucumber.
>>
>> We need to stub time in some of our scenarios, which exist to to
>> verify
>> behavior over time. We're looking into a before/after to support
>> mocking/stubbing for this scenario.
>
> There's no direct hooks into the mock framework and I don't think
> there should be, but you can roll your own in the supplied
> Before/After methods:
>
> Before do
> #do some magic w/ time
> end
>
> After do
> #undo some magic w/ time
> end
>
> Those run before and after every scenario.
How would you do this? I guess you could just require spec/mocks/
mock, mock / stub as usual, and then in the After block call
Spec::Mocks::Space#reset_all ?
Scott
That could work. And actually, I'd be OK w/ the idea of stubs, just
not message expectations (mocks).
Aslak?
> On Sep 30, 2008, at 11:06 AM, David Chelimsky wrote:
>
>> On Tue, Sep 30, 2008 at 9:55 AM, Luke Melia <lu...@lukemelia.com>
>> wrote:
>>> On Sep 15, 2008, at 4:35 PM, Pat Maddox wrote:
>>>
>>>> I don't think you're really supposed to mock or stub when using
>>>> cucumber.
>>>
>>> We need to stub time in some of our scenarios, which exist to to
>>> verify
>>> behavior over time. We're looking into a before/after to support
>>> mocking/stubbing for this scenario.
>>
>> There's no direct hooks into the mock framework and I don't think
>> there should be, but you can roll your own in the supplied
>> Before/After methods:
>>
>> Before do
>> #do some magic w/ time
>> end
>>
>> After do
>> #undo some magic w/ time
>> end
>>
>> Those run before and after every scenario.
>
> How would you do this? I guess you could just require spec/mocks/
> mock, mock / stub as usual, and then in the After block call
> Spec::Mocks::Space#reset_all ?
You can do magic without mocks...
orig_now = Time.method(:now)
Before do
now = Time.now
(class << Time; self; end).send(:define_method, :now) { now }
end
After do
(class << Time; self; end).send(:define_method, :now) { orig_now.call }
end
Pat
Sure. If our mocks were macros, wouldn't it expand into this code?
Scott
I forked it and struggled with getting GitHub gems deployer to behave
itself.
Maybe a "canonical" version can be kept and updated in RubyForge
occasionally because of occasional gem problems with GitHub?
Evan
> We need to stub time in some of our scenarios, which exist to to
> verify behavior over time. We're looking into a before/after to
> support mocking/stubbing for this scenario.
Thanks for everyone's thoughts. I understand that mocks are generally
an anathema to story tests. We've decided to use them to solve this
particular problem, though, and rely on our own self-discipline to not
abuse their presence. Here's what we're going with for now in our
env.rb:
require 'spec/mocks'
require File.expand_path(File.join(File.dirname(__FILE__), "..", "..",
"vendor", "plugins", "rspec", "plugins", "mock_frameworks", "rspec"))
include Spec::Plugins::MockFramework
Before do
setup_mocks_for_rspec
end
After do
begin
verify_mocks_for_rspec
ensure
teardown_mocks_for_rspec
end
end
You can do that with git pull and git checkout. Would it help if
detailed instructions were posted to the wiki?
> I forked it and struggled with getting GitHub gems deployer to behave
> itself.
>
> Maybe a "canonical" version can be kept and updated in RubyForge
> occasionally because of occasional gem problems with GitHub?
>
Yes, I'll probably do that soon. GitHub fails to build the gem every
time for me (not occasionally).
http://logicalawesome.lighthouseapp.com/projects/8570-github/tickets/945
Aslak
On Tue, Sep 30, 2008 at 9:02 PM, Evan David Light
<li...@tiggerpalace.com> wrote:Subject says most of it. I'd love to use Cucumber in my project but I needto be able to install it in a Rails app and by a particular version number.
You can do that with git pull and git checkout. Would it help if
detailed instructions were posted to the wiki?
Maybe a "canonical" version can be kept and updated in RubyForgeoccasionally because of occasional gem problems with GitHub?
Yes, I'll probably do that soon. GitHub fails to build the gem every
time for me (not occasionally).
http://logicalawesome.lighthouseapp.com/projects/8570-github/tickets/945
On Tue, Sep 30, 2008 at 9:02 PM, Evan David LightYou can do that with git pull and git checkout. Would it help if
<li...@tiggerpalace.com> wrote:
> Subject says most of it. I'd love to use Cucumber in my project but I need
> to be able to install it in a Rails app and by a particular version number.
>
detailed instructions were posted to the wiki?
Yes, I'll probably do that soon. GitHub fails to build the gem every
> I forked it and struggled with getting GitHub gems deployer to behave
> itself.
>
> Maybe a "canonical" version can be kept and updated in RubyForge
> occasionally because of occasional gem problems with GitHub?
>
time for me (not occasionally).
http://logicalawesome.lighthouseapp.com/projects/8570-github/tickets/945
Aslak
> Evan
> _______________________________________________
> rspec-users mailing list
> rspec...@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Have you tried this?
export http_proxy=http://yourproxy:yourport
git clone http://github.com/aslakhellesoy/cucumber
git checkout SHA-of-the-rev-you-want
> Would it be too much to ask if you could tag the repo when you jump
> to a new release, like David is doing with rspec?
>
Absolutely - I'll tag it when there is a release. And push a gem to
RubyForge. But there hasn't been one yet.
> Github lets you download a snapshot of the repo by tags, and I just build
> the gems from that, and toss them up into a behind-the-firewall gem server,
> and let everyone gem install from there. It's a bit harder with cucumber,
> because I'm not sure where the "released, stable" point is ...
>
It's whenever I feel like it and have some spare time :-) Probably
within the next week or so.
Aslak
On Wed, Oct 1, 2008 at 5:11 PM, Chris Flipse <cfl...@gmail.com> wrote:Have you tried this?
> On Tue, Sep 30, 2008 at 5:20 PM, aslak hellesoy <aslak.h...@gmail.com>
> wrote:
>>
>> On Tue, Sep 30, 2008 at 9:02 PM, Evan David Light
>> <li...@tiggerpalace.com> wrote:
>> > Subject says most of it. I'd love to use Cucumber in my project but I
>> > need
>> > to be able to install it in a Rails app and by a particular version
>> > number.
>> >
>>
>> You can do that with git pull and git checkout. Would it help if
>> detailed instructions were posted to the wiki?
>
> That gets you whatever the latest is, which is good if you want to live on
> edge. I'm behind a firewall, and living on edge isn't necessarily a good
> option.
export http_proxy=http://yourproxy:yourport
git clone http://github.com/aslakhellesoy/cucumber
git checkout SHA-of-the-rev-you-want
Absolutely - I'll tag it when there is a release. And push a gem to
> Would it be too much to ask if you could tag the repo when you jump
> to a new release, like David is doing with rspec?
>
RubyForge. But there hasn't been one yet.
I can feel your pain. I have worked for this kind of clients.
Insurance and government. They don't seem to understand how big an
impediment this is. And that people who need to work around this (us)
will do it anyway to get work done. It's just stupid.
>>
>> > Would it be too much to ask if you could tag the repo when you jump
>> > to a new release, like David is doing with rspec?
>> >
>>
>> Absolutely - I'll tag it when there is a release. And push a gem to
>> RubyForge. But there hasn't been one yet.
>
> Ah. I'd been going on the assumption that the occasional gem version bumps
> were signifying real checkpoints. If not, then, I havn't yet been burned by
> pulling down head once a week or so
No, actually - it's been me trying to convince the GitHub pixies to
build the gem. To no avail.
Aslak
> --
> // anything worth taking seriously is worth making fun of
> // http://blog.devcaffeine.com/
>
> No, actually - it's been me trying to convince the GitHub pixies to
> build the gem. To no avail.
Not to belabor a point overly but hence my suggestion to put a gem on
RubyForge.
I'm dying for a stable version of Cucumber -- even if it's only
"stable" ;-)
Evan
> No, actually - it's been me trying to convince the GitHub pixies to
> build the gem. To no avail.
Have we witnessed the birth of Pixie Driven Development this week? I
feel like we need PixieSpec and Pixie Stories next :)
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
>
> On 1 Oct 2008, at 16:53, aslak hellesoy wrote:
>
>> No, actually - it's been me trying to convince the GitHub pixies to
>> build the gem. To no avail.
>
> Have we witnessed the birth of Pixie Driven Development this week?
> I feel like we need PixieSpec and Pixie Stories next :)
>
No, I think it's a matter of "GitHub Driven Deployment" -- or non-
Deployment as the case would be. :-/
Evan
I hear ya brother, same here, luckily not anymore.
you can do the following (at home):
gem search cucumber --remote --source http://gems.github.com
gem fetch cucumber --source http://gems.github.com
This will put the .gem file in the folder you performed the task for
you to easily copy to your locked down environment :-D
>>
>> > Would it be too much to ask if you could tag the repo when you jump
>> > to a new release, like David is doing with rspec?
>> >
>>
>> Absolutely - I'll tag it when there is a release. And push a gem to
>> RubyForge. But there hasn't been one yet.
>
> Ah. I'd been going on the assumption that the occasional gem version bumps
> were signifying real checkpoints. If not, then, I havn't yet been burned by
> pulling down head once a week or so
Github gems are only updated when the cucumber.gemspec file is updated.
--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams
Yes, but only in theory:
http://logicalawesome.lighthouseapp.com/projects/8570-github/tickets/945
Does anyone want Cucumber gems? No? Yes? Anyone? OK I HEARD YOU! :-)
http://rubyforge.org/frs/?group_id=797
Just chill till it rsyncs around. Install docs are updated:
http://github.com/aslakhellesoy/cucumber/wikis/home
Aslak
Does anyone want Cucumber gems? No? Yes? Anyone? OK I HEARD YOU! :-)
http://rubyforge.org/frs/?group_id=797
Just chill till it rsyncs around. Install docs are updated:
http://github.com/aslakhellesoy/cucumber/wikis/home