Keith McDonnell
2007-Mar-24 14:45 UTC
[rspec-users] Using spec fixtures with integration tests
Hi all,
How can I use spec fixtures with rails integration tests ?
I''ve tried adding {{ fixtures "../../spec/fixtures/myfixture"
}}
to the integration test but the fixtures are not loaded when I run the
rake task.
Rails doesn''t load symlinked fixtures either so I copied the files from
spec/fixtures for the time being. Not very DRY.
Any ideas ?
Keith
rspec-users-request at rubyforge.org wrote:> Send rspec-users mailing list submissions to
> rspec-users at rubyforge.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://rubyforge.org/mailman/listinfo/rspec-users
> or, via email, send a message with subject or body ''help''
to
> rspec-users-request at rubyforge.org
>
> You can reach the person managing the list at
> rspec-users-owner at rubyforge.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rspec-users digest..."
>
>
> Today''s Topics:
>
> 1. spec''ing metaprograming & rails CRUD (Scott Taylor)
> 2. Re: State Based vs. Behaviour Based Spec/Testing (David Chelimsky)
> 3. Re: State Based vs. Behaviour Based Spec/Testing (David Chelimsky)
> 4. Re: State Based vs. Behaviour Based Spec/Testing (aslak hellesoy)
> 5. Re: spec''ing metaprograming & rails CRUD (Michael Trier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Mar 2007 05:11:04 -0400
> From: Scott Taylor <mailing_lists at railsnewbie.com>
> Subject: [rspec-users] spec''ing metaprograming & rails CRUD
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <6CB12C20-54B1-4043-8C07-D1E3E9C92BC2 at railsnewbie.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> For edge rails there is a Crud generator. There is also a CRUD
> controller that is out there from which you can inherit your other
> controllers (see http://geekonomics.blogspot.com/2006/07/crud-and-
> shared-controllers.html)
>
> This got me thinking about Crud controllers in general. As far as I
> know, the generator can''t produce crud classes which are nested
> (i.e. /posts/1/comments/7). So I thought about creating my own Crud
> class from which to inherit from, with some private methods, like so:
>
> class CrudController < ActiveRecord::Base
> class << self
> private
> def model
> # get a default name based on the controller name
> # or specify a name
> end
>
> def belongs_to
> # the model''s "belongs_to"/foreign key
relationship
> # this could also be found dynamically
> end
> end
> end
>
> class CommentsController < CrudController
> model :comments
> belongs_to :post
> end
>
> And then this would generate the typical nested crud, with
> before_filter and all of that jazz
>
> Anyway, here goes my question. The CrudController''s specs should
set
> a bunch of instance variables (such as @comments = @post.comments)
> and a bunch of instance methods in the Comments controller. How
> would I spec out such a thing? I would have to use reflection in The
> CRUD controller - do a bunch of no-no''s, like use
> private_instance_methods, send, etc. to get to the private class methods
>
> So It looks like I should just create a CommentsController instance,
> and spec that. But now how do I practice test-first development on
> the CrudController?
>
> I have also been thinking a little bit about the specs of Rubinius.
> I have no idea how it is implemented, but I''m sure each class will
> have a symbol table, etc. etc. The high level spec''s will look
> something like the following:
>
> specify "+ should concatenate two arrays" do
> example do
> [ 1, 2, 3 ] + [ 4, 5 ]
> end.should == [1, 2, 3, 4, 5]
> end
>
> How Rubininus creates the Arrays, sets them up in the symbol table/
> creates an object id, etc. - All of this, the spec will never touch.
> How is one to do test first development on this sort of thing? If
> the methods involved get too big, they will probably be refactored
> into private methods. So how does one practice BDD on private
> methods? Or should one just assume that they will work?
>
> These sorts of things are the things I was thinking about in my last
> email. As I see it, spec''ing/testing is used for the following:
> 1. Verification of Code Working the way you expect it to. This is
> more fine grained, and better suited to Test::Unit, although the code
> can easily break after refactoring.
> 2. Documentation
> 3. Test-First development. What small piece do I implement next?
> (Think of the Rubinus/private methods example)
> 4. Defining Behaviour, which of course, is simply high level
> verification on exposed methods.
>
>
> Thoughts on these matters?
>
> Scott
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 24 Mar 2007 07:19:20 -0500
> From: "David Chelimsky" <dchelimsky at gmail.com>
> Subject: Re: [rspec-users] State Based vs. Behaviour Based
> Spec/Testing
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID:
> <57c63afe0703240519q40ae8a62v34672b71874fc383 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>> I''ve notice that a project like Rubinius has both a spec &
a test
>> directory. Rspec has only a spec directory. Obviously I support
>> BDD, but isn''t there also a place for state based/verification
>> testing?
>
> BDD is not a tool. BDD is a way of thinking about TDD. BDD *is* TDD,
> with focus (not exclusivity) on behaviour. This is what I believe to
> be the initial intent of TDD. This doesn''t mean that all state
testing
> is bad. In fact, most of the expectations in rspec are state-based:
> actual.should == value, etc.
>
> I think you''re confusing Interaction testing with BDD. Interaction
> testing is a very important part of BDD, but it is not the sole
> purview of BDD. Mocks have been around for a long time. I can''t
really
> think of anything that you can do with rspec that you can''t do w/
> test/unit and mocha. RSpec just tries to make it easier to focus on
> behaviour by using less "testy" words.
>
>> I sometimes sense that I *do* want to practice Test Driven
>> Development. That is, I want some assurance that my production code
>> will run as intended. But I also want some verification of a bug
>> right after I have implemented it.
>
> Many people fix bugs using TDD. When the bug is reported, just start
> by writing a failing test that exposes the bug.
>
> Keep in mind that when doing TDD, the nature of the tests change very
> quickly. When you write the failing test, your goal is expose a
> missing or incorrect behaviour, and use the resulting test to drive
> your design. As soon as that test is passing, it changes in nature,
> becoming both documentation and a regression test.
>
>> How can one truly get away from state based testing to some degree?
>
> You can''t. At least not in my experience.
>
>> Spec''s often seem too "high level" to assure the
"testing" of the code.
>
> Again, this has to do w/ approach. You can write low level specs just
> as you can write high-level tests. The trick is balance, keeping the
> focus on behaviour rather than the internal structure of code.
>
>> I know that Test::Unit code will always be brittle. What happens
>> when the code is refactored? It is sure to break.
>> Does this suggest that Test::Unit code should be written right after
>> development is done, covering the internals of the project?
>
> Again, this is a matter of approach, not tooling. Assuming that you
> *must* test something internal, there''s no reason that you
can''t do it
> with rspec. But if you are testing internals, I''d reflect on that
and
> ask yourself why it is important to do so. Ask yourself how the
> behaviour is going to be different if the internals change. I''ll
bet
> that most (not all) of the time, you''ll be able to find ways to
> express your "testing" concerns in terms of behaviour. If you can
do
> that without having to get too far away from the code to do so,
you''re
> better off because you''ll have better documentation and less
brittle
> tests.
>
> We should really be talking about specific examples, because there are
> some principles here that are either not being recognized or dying to
> get out. Feel free to post some.
>
>> Maybe
>> BDD specs should be written first, using TDD with Test::Unit for
>> verification (as throw-away code)? Or do mock objects solve all of
>> these problems?
>>
>> The real question is, do you spec''ers think there is any place
for a
>> testing framework next to a spec''ing framework?
>
> Heretical though this may seem: RSPEC IS A TESTING FRAMEWORK. There, I said
it.
>
> Scott - I don''t mean to pick on you here. In fact, I thank you for
> posting this because a lot has been said during the early phases of
> BDD''s evolution that is confusing and obviously misleading. And,
in
> fact, much of this has been said by me as I''ve been exploring what
the
> meaning of BDD is ... to me.
>
> I hope that you''ll keep posting questions like this as they can
only
> help us all to clarify things.
>
> Cheers,
> David
>
>> Best,
>>
>> Scott Taylor
>>
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 24 Mar 2007 08:08:57 -0500
> From: "David Chelimsky" <dchelimsky at gmail.com>
> Subject: Re: [rspec-users] State Based vs. Behaviour Based
> Spec/Testing
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID:
> <57c63afe0703240608m1021ac3dx52812572a014d82f at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>>> I''ve notice that a project like Rubinius has both a spec
& a test
>>> directory. Rspec has only a spec directory. Obviously I support
>>> BDD, but isn''t there also a place for state
based/verification
>>> testing?
>> BDD is not a tool. BDD is a way of thinking about TDD. BDD *is* TDD,
>> with focus (not exclusivity) on behaviour. This is what I believe to
>> be the initial intent of TDD. This doesn''t mean that all state
testing
>> is bad. In fact, most of the expectations in rspec are state-based:
>> actual.should == value, etc.
>>
>> I think you''re confusing Interaction testing with BDD.
Interaction
>> testing is a very important part of BDD, but it is not the sole
>> purview of BDD. Mocks have been around for a long time. I
can''t really
>> think of anything that you can do with rspec that you can''t do
w/
>> test/unit and mocha. RSpec just tries to make it easier to focus on
>> behaviour by using less "testy" words.
>>
>>> I sometimes sense that I *do* want to practice Test Driven
>>> Development. That is, I want some assurance that my production code
>>> will run as intended. But I also want some verification of a bug
>>> right after I have implemented it.
>> Many people fix bugs using TDD. When the bug is reported, just start
>> by writing a failing test that exposes the bug.
>>
>> Keep in mind that when doing TDD, the nature of the tests change very
>> quickly. When you write the failing test, your goal is expose a
>> missing or incorrect behaviour, and use the resulting test to drive
>> your design. As soon as that test is passing, it changes in nature,
>> becoming both documentation and a regression test.
>>
>>> How can one truly get away from state based testing to some degree?
>> You can''t. At least not in my experience.
>>
>>> Spec''s often seem too "high level" to assure the
"testing" of the code.
>> Again, this has to do w/ approach. You can write low level specs just
>> as you can write high-level tests. The trick is balance, keeping the
>> focus on behaviour rather than the internal structure of code.
>>
>>> I know that Test::Unit code will always be brittle. What happens
>>> when the code is refactored? It is sure to break.
>>> Does this suggest that Test::Unit code should be written right
after
>>> development is done, covering the internals of the project?
>> Again, this is a matter of approach, not tooling. Assuming that you
>> *must* test something internal, there''s no reason that you
can''t do it
>> with rspec. But if you are testing internals, I''d reflect on
that and
>> ask yourself why it is important to do so. Ask yourself how the
>> behaviour is going to be different if the internals change.
I''ll bet
>> that most (not all) of the time, you''ll be able to find ways
to
>> express your "testing" concerns in terms of behaviour. If you
can do
>> that without having to get too far away from the code to do so,
you''re
>> better off because you''ll have better documentation and less
brittle
>> tests.
>>
>> We should really be talking about specific examples, because there are
>> some principles here that are either not being recognized or dying to
>> get out. Feel free to post some.
>>
>>> Maybe
>>> BDD specs should be written first, using TDD with Test::Unit for
>>> verification (as throw-away code)? Or do mock objects solve all of
>>> these problems?
>>>
>>> The real question is, do you spec''ers think there is any
place for a
>>> testing framework next to a spec''ing framework?
>> Heretical though this may seem: RSPEC IS A TESTING FRAMEWORK. There, I
said it.
>>
>> Scott - I don''t mean to pick on you here. In fact, I thank you
for
>> posting this because a lot has been said during the early phases of
>> BDD''s evolution that is confusing and obviously misleading.
And, in
>> fact, much of this has been said by me as I''ve been exploring
what the
>> meaning of BDD is ... to me.
>>
>> I hope that you''ll keep posting questions like this as they
can only
>> help us all to clarify things.
>
> I should also add that I''m talking about BDD as applied to
isolation
> testing (what many call unit testing :) ). BDD has really evolved into
> an agile practice that comprises TDD, Acceptance Test Driven Planning
> and other concepts that are geared towards increasing communication
> and understanding within the context of a software project. If this is
> new to you, check out http://dannorth.net/introducing-bdd/.
>
>> Cheers,
>> David
>>
>>> Best,
>>>
>>> Scott Taylor
>>>
>>>
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 24 Mar 2007 14:11:12 +0100
> From: "aslak hellesoy" <aslak.hellesoy at gmail.com>
> Subject: Re: [rspec-users] State Based vs. Behaviour Based
> Spec/Testing
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID:
> <8d961d900703240611u3e79baa0w5c795d72dae5697e at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>> I''ve notice that a project like Rubinius has both a spec &
a test
>> directory. Rspec has only a spec directory. Obviously I support
>> BDD, but isn''t there also a place for state based/verification
>
> Anyone is free to write their code who they want. RSpec doesn''t
> mandate any particular style, it just encourages it.
>
>> testing? I sometimes sense that I *do* want to practice Test Driven
>> Development.
>
> Ok. BDD is just a kind of TDD with a stronger focus on "tell
don''t
> ask", mocking and intent.
>
>> That is, I want some assurance that my production code
>> will run as intended. But I also want some verification of a bug
>> right after I have implemented it.
>>
>> How can one truly get away from state based testing to some degree?
>
> Use mocking to drive out interaction between objects. Strive for a
> "tell don''t ask" design (look it up).
>
>> Spec''s often seem too "high level" to assure the
"testing" of the code.
>>
>
> What do you mean?
>
>> I know that Test::Unit code will always be brittle. What happens
>> when the code is refactored? It is sure to break.
>>
>
> Huh? What is it about Test::Unit that makes it inherently brittle?
> I have no idea what you are talking about here.
>
>> Does this suggest that Test::Unit code should be written right after
>> development is done, covering the internals of the project?
>
> If you''re doing TDD, no - you write tests before the code. If
you''re
> "just using Test::Unit" you can write it when you want.
>
>> Maybe
>> BDD specs should be written first, using TDD with Test::Unit for
>
> BDD *is* TDD, with some extra philosophical baggage. You write specs
> before the code in both BDD and TDD.
>
>> verification (as throw-away code)? Or do mock objects solve all of
>> these problems?
>>
>
> What problems?
>
>> The real question is, do you spec''ers think there is any place
for a
>> testing framework next to a spec''ing framework?
>>
>
> To solve what problem?
>
> Aslak
>
>> Best,
>>
>> Scott Taylor
>>
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 24 Mar 2007 09:32:06 -0400
> From: Michael Trier <mtrier at eminentconsultinggroup.com>
> Subject: Re: [rspec-users] spec''ing metaprograming & rails
CRUD
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID:
> <6F1FD75F-2451-48A3-98AE-1F806963AE2F at eminentconsultinggroup.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Mar 24, 2007, at 5:11 AM, Scott Taylor wrote:
>
>> For edge rails there is a Crud generator. There is also a CRUD
>> controller that is out there from which you can inherit your other
>> controllers (see http://geekonomics.blogspot.com/2006/07/crud-and-
>> shared-controllers.html)
>>
>> This got me thinking about Crud controllers in general. As far as I
>> know, the generator can''t produce crud classes which are
nested
>> (i.e. /posts/1/comments/7). So I thought about creating my own Crud
>> class from which to inherit from, with some private methods, like so:
>>
>> class CrudController < ActiveRecord::Base
>> class << self
>> private
>> def model
>> # get a default name based on the controller name
>> # or specify a name
>> end
>>
>> def belongs_to
>> # the model''s "belongs_to"/foreign key
relationship
>> # this could also be found dynamically
>> end
>> end
>> end
>>
>> class CommentsController < CrudController
>> model :comments
>> belongs_to :post
>> end
>
> You might want to look into the resource_controller plugin: (http://
> svn.ardes.com/rails_plugins/resources_controller/
>
> It does what you''re describing in a very nice way and supports
nested
> as well as acts_as_tree situations.
>
> Michael
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070324/47027130/attachment.html
>
> ------------------------------
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> End of rspec-users Digest, Vol 9, Issue 16
> ******************************************
>
>
Possibly Parallel Threads
Wisdom of the Ancients
