[rspec-users] Using spec fixtures with integration tests

Keith McDonnell keith at dancingtext.com
Sat Mar 24 10:45:57 EDT 2007


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
> ******************************************
> 
> 


More information about the rspec-users mailing list