Sent from my iPhone.
On Oct 31, 2008, at 14:35, 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. Re: Help: Attempts to run specs quitting midstream (Scott Taylor)
> 2. Re: Mocks and Refactoring - doing it wrong? (Scott Taylor)
> 3. Re: spec''ing the :conditions argument of a find (Matt Wynne)
> 4. Re: spec''ing the :conditions argument of a find (Ashley
Moran)
> 5. described_type (Matt Wynne)
> 6. Re: described_type (Pat Maddox)
> 7. Re: testing a render layout statement in a controller
> (Harry Bishop)
> 8. Re: Working outside-in with Cucumber and RSpec (Nick Hoffman)
> 9. Fwd: spec_server not working... (Matt Darby)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 30 Oct 2008 21:23:31 -0400
> From: Scott Taylor <mailing_lists at railsnewbie.com>
> Subject: Re: [rspec-users] Help: Attempts to run specs quitting
> midstream
> To: rspec-users at rubyforge.org
> Message-ID: <34EB771B-DED1-4031-A242-F2FC81AE761E at railsnewbie.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Oct 30, 2008, at 8:21 PM, Evan Dorn wrote:
>
>> I am having a very frustrating problem running specs on my current
>> project. When I run tests en masse with "rake spec" or with
>> autotest,
>> it frequently quits without completing all the tests. It also
>> sometimes runs the tests in multiple batches, giving more than one
>> result line for a single batch of tests.
>>
>> For example, on my current project (which has in total 524
>> examples), it
>> currently runs a batch of 31 examples (with 0 failures), outputs a
>> result line, then runs a batch of 131 examples (with 3 failures),
>> outputs a result line, then reports "rake aborted" with
"command
>> <long
>> command here> failed".
>>
>> If I put --reverse in spec.opts, it quits in a different place
>> after a
>> different number of specs.
>>
>> If I run with --trace, it reports that the final complaint is in
>> spectask.rb line 177. This is a line that looks for error results
>> when
>> it executes the command with system().
>>
>> As far as I can tell, there is no way for me to know which spec file
>> was
>> actually executing when it quit. Very frustrating.
>>
>> System information:
>> OS X 10.5.5
>> Ruby 1.8.6
>> rspec 1.1.11
>>
>>
>> Below is an shell transcript. If this had run successfully, there
>> would be 524 examples run, instead of 31 and then 131. The
>> particular
>> numbers change as I edit my files.
>>
>> Thanks for any help, I''m tearing my hair out here.
>
> I''d file this bug report at lighthouse:
>
> http://rspec.lighthouseapp.com/dashboard
>
> Scott
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 30 Oct 2008 21:24:14 -0400
> From: Scott Taylor <mailing_lists at railsnewbie.com>
> Subject: Re: [rspec-users] Mocks and Refactoring - doing it wrong?
> To: rspec-users at rubyforge.org
> Message-ID: <6D3B0233-51F7-4083-B95A-44FDF12F1EEF at railsnewbie.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Oct 30, 2008, at 7:52 PM, Sebastian W. wrote:
>
>>> No idea why you couldn''t pass a flag for regression
testing:
>>>
>>> mock(Foo, :check_methods => true)
>>>
>>> Scott
>>
>> It seems to me this way, too - though I''m obviously biased. :)
>>
>> It''s true that a lot of the dynamic stuff could be problematic
-
>> what if
>> the flag was only for checking methods directly implemented on that
>> class? Though I guess that''d lead down a potential dark path
where
>> you''d
>> then also want the "mock" method to potentially check all
mixins and
>> validate, etc. etc.
>>
>> On the other hand, maybe it could serve as a gentle remonstrance to
>> folks to not overdo it with the "i am an 3l337 ninj4 haxx0r"
>> metaprogramming? Just a thought.
>
> +1
>
> Tests *are* supposed to influence the way we write production code.
>
> Scott
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 31 Oct 2008 07:49:25 +0000
> From: Matt Wynne <matt at mattwynne.net>
> Subject: Re: [rspec-users] spec''ing the :conditions argument of a
find
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <8E053474-34E5-4753-866D-DF549A06EFE3 at mattwynne.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On 30 Oct 2008, at 20:11, Pat Maddox wrote:
>> Matt Wynne <matt at mattwynne.net> writes:
>>
>>> On 30 Oct 2008, at 15:58, Zach Dennis wrote:
>>>> I know the above example breaks the one assertion per test
>>>> guideline
>>>> people strive to adhere to, but I think it is ok. If there are
>>>> more
>>>> examples that should be used to make sure find_thingy works
then
>>>> I''d
>>>> break out a separate describe block and have multiple
''it''
>>>> examples,
>>>
>>> It also goes to the database, which will make it a slow unit test.
I
>>> personally do pretty much the same thing myself mostly when working
>>> with ActiveRecord, but it doesn''t mean I''m
comfortable with it. (And
>>> it also doesn''t mean our unit test suite is anything other
than
>>> shamefully slow)
>>>
>>> I did experiment with a QueryApapter for this purpose which has
>>> worked
>>> out quite well for us. You end up with code like this in the
>>> Controller:
>>
>> Scott is working on a SQL parser which would let you write tests that
>> "hit" the db but keep everything in memory and fast. Might
be worth
>> checking out for you.
>
> Sounds interesting. I''d still like to see us have a proper ORM for
> ruby that lets us play with POROs 90% of the time, and just have a
> separate suite of tests for the database-object mappings that we run
> when necessary.
>
> cheers,
> Matt
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 31 Oct 2008 08:24:03 +0000
> From: Ashley Moran <ashley.moran at patchspace.co.uk>
> Subject: Re: [rspec-users] spec''ing the :conditions argument of a
find
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <D08C4FE6-33DF-4A61-96F7-95141C98C640 at
patchspace.co.uk>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Oct 31, 2008, at 7:49 am, Matt Wynne wrote:
>
>>>> It also goes to the database, which will make it a slow unit
>>>> test. I
>>>> personally do pretty much the same thing myself mostly when
working
>>>> with ActiveRecord, but it doesn''t mean I''m
comfortable with it.
>>>> (And
>>>> it also doesn''t mean our unit test suite is anything
other than
>>>> shamefully slow)
>>
>> <snip>
>>
>> Sounds interesting. I''d still like to see us have a proper ORM
for
>> ruby that lets us play with POROs 90% of the time, and just have a
>> separate suite of tests for the database-object mappings that we run
>> when necessary.
>
> I''m using DataMapper in a (non-web) project I have on now, and for
> part of the spec suite where I am concerned with persistence as a
> black-box, I create an in-memory SQLite database:
>
> # story_spec.rb
>
> describe "Class", Story do
>
> # ...
>
> describe ".unposted" do
> include InMemoryDatabase
>
> before(:each) do
> setup_in_memory_database
>
> @twitter_client = mock(TwitterAgent::Client, :post_story =>
> true)
>
> @story_1 = Story.create(:title => "Story title 1",
> :published_at => DateTime.new(2008,
> 9, 28))
> @story_2 = Story.create(:title => "Story title 2",
> :published_at => DateTime.new(2008,
> 9, 29))
> @story_3 = Story.create(:title => "Story title 3",
> :published_at => DateTime.new(2008,
> 9, 27))
> end
>
> it "should find all stories (in ascending published date)
> when none have been posted" do
> Story.unposted.should == [ @story_3, @story_1, @story_2 ]
> end
>
> it "should find only unpublished stories (in ascending
> published date)" do
> @story_1.post_to_twitter!(@twitter_client)
> Story.unposted.should == [ @story_3, @story_2 ]
> end
>
> end
> end
>
> # spec_helper.rb
>
> module InMemoryDatabase
> def setup_in_memory_database
> DataMapper.setup(:default, "sqlite3::memory:")
> Database::Migrator.new.reset_database!
> end
> end
>
> Aside from being unable to use DB-lever constraints, that gives me
> enough confidence in the persistence. Other specs that don''t need
> persistence simply omit the "setup_in_memory_database" call.
>
> It''s important not to lose sight of the fact that, even though
> ActiveRecord mixes business logic and persistence, *they are still
> separate concerns*.
>
> Ashley
>
>
> --
> http://www.patchspace.co.uk/
> http://aviewfromafar.net/
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 31 Oct 2008 09:36:28 +0000
> From: Matt Wynne <matt at mattwynne.net>
> Subject: [rspec-users] described_type
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <2F793D35-C491-46B8-8BF2-3EB8FEF1A17F at mattwynne.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> I heard somebody mention described_type the other day, so I thought
> I''d give it a spin.
>
> It doesn''t seem to behave as I''m expecting though.
>
> I have a method which generates examples to verify AR associations:
>
> def it_should_have_many(klass, association, opts = {})
> it "should relate to #{association}" do
> klass.reflect_on_association(association).should_not
> be_nil
> end
>
> it "should have many #{association}" do
> klass.reflect_on_association(association).macro.should
> == :has_many
> end
>
> if opts[:as]
> it "should relate to #{association} as :subject" do
>
> klass.reflect_on_association(association).options[:as].should =>
opts[:as]
> end
> end
> end
>
> So at the moment, I have to call it like this:
>
> it_should_have_many Post, :attachments, :as => :comments
>
> Which is a bit ugly. I figured I could use described_type instead of
> klass in the example-generating method, but it doesn''t work:
>
> undefined local variable or method `described_type'' for
> #<
> Spec
> ::Rails
> ::Example
> ::ModelExampleGroup::Subclass_1::Subclass_1::Subclass_1:0x21518bc>
>
> What dumb thing am I doing wrong?
>
> cheers,
> Matt
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 31 Oct 2008 03:50:30 -0700
> From: Pat Maddox <pergesu at gmail.com>
> Subject: Re: [rspec-users] described_type
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <m23aid3uo9.fsf at paltswif01.r2.pt.cox.cci>
> Content-Type: text/plain; charset=us-ascii
>
> Matt Wynne <matt at mattwynne.net> writes:
>
>> I figured I could use described_type instead of
>> klass in the example-generating method, but it doesn''t work:
>>
>> undefined local variable or method `described_type'' for
#<
>> Spec ::Rails ::Example
>> ::ModelExampleGroup::Subclass_1::Subclass_1::Subclass_1:0x21518bc>
>>
>> What dumb thing am I doing wrong?
>
> self.class.described_type
>
> Pat
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 31 Oct 2008 18:26:17 +0100
> From: Harry Bishop <lists at ruby-forum.com>
> Subject: Re: [rspec-users] testing a render layout statement in a
> controller
> To: rspec-users at rubyforge.org
> Message-ID: <d17bee302adc000eb295f8445d31707c at ruby-forum.com>
> Content-Type: text/plain; charset=utf-8
>
> Bart Zonneveld wrote:
>> On 16-okt-2008, at 8:50, Dave Gamphani Phiri wrote:
>>
>>> Here, I was trying to test if the out put displays with a layouts/
>>> menu
>>> template.
>>> Can somebody help on how you test the render(:layout =>
"layouts/
>>> menu") statement in a controller or this is supposed to be
tested in
>>> the view?
>>
>> Try this:
>>
>> render(:layout => "layouts/menu") and return
>>
>> cheers,
>> bartz
>
> Thanks Bartz, I used your input to try a controller line of
> format.html { render :action => "show" }
> and rspec of
> response.should render_template( :(controller name) =>
"/show")
>
> I tried it with and without the "and return" and both worked.
>
> Harry
>
>
> --
> Posted via http://www.ruby-forum.com/.
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 31 Oct 2008 16:54:42 -0400
> From: Nick Hoffman <nick at deadorange.com>
> Subject: Re: [rspec-users] Working outside-in with Cucumber and RSpec
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <364B2A62-F8E2-4159-924E-878B29E2AC3C at deadorange.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On 2008-10-30, at 15:31, Pat Maddox wrote:
>> eh I dunno. I mean, I completely agree that hard-to-write tests
>> often
>> expose bad code. But there isn''t any gray area when it comes
to
>> designing Rails controllers, in my opinion. I see an action
that''s
>> more
>> than five lines long and I know it''s wrong. I don''t
need to write
>> examples to tell me that.
>
> Hi Pat. Would you mind suggesting how I can make this 22-line action a
> bit shorter? =)
> http://refactormycode.com/codes/575-dry-up-a-controller-action
>
> Thanks!
> Nick
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 31 Oct 2008 17:34:59 -0400
> From: Matt Darby <matt at matt-darby.com>
> Subject: [rspec-users] Fwd: spec_server not working...
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID: <4AE03859-BEC1-4ACF-AF91-AE189D8386CB at matt-darby.com>
> Content-Type: text/plain; charset="us-ascii";
Format="flowed";
> DelSp="yes"
>
> I can''t seem to get spec_server to work correctly (I''ve
never used it
> before, so maybe I''m missing something?)
>
> I start up spec_server as prescribed:
> mdarby at macbook:~/Documents/apps/CCW: rake spec:server:start
> (in /Users/mdarby/Documents/Apps/CCW)
> Starting up spec server.
> Loading Rails environment
> Ready
> spec_server launched. (PID: 31387)
>
>
> Then I try to run a spec and it times out after about thirty seconds:
> mdarby at macbook:~/Documents/apps/CCW: ./script/spec --drb spec/models/
> job_spec.rb
> No server is running
>
> ^C/usr/local/lib/ruby/1.8/drb/drb.rb:566:in `read'': Interrupt
> from /usr/local/lib/ruby/1.8/drb/drb.rb:566:in `load''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:632:in
`recv_reply''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:923:in
`recv_reply''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:1202:in
`send_message''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:1093:in
> `method_missing''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:1177:in `open''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:1092:in
> `method_missing''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:1110:in
`with_friend''
> from /usr/local/lib/ruby/1.8/drb/drb.rb:1091:in
> `method_missing''
> from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/
> runner/drb_command_line.rb:13:in `run''
> from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/
> runner/option_parser.rb:184:in `parse_drb''
> from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/
> runner/option_parser.rb:124:in `order!''
> from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/
> runner.rb:202:in `options''
> from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/
> runner/command_line.rb:8:in `run''
> from ./script/spec:5
>
> Gems installed:
> rspec (1.1.11)
> rspec-rails (1.1.11)
>
> Any thoughts?
>
> Thanks!
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081031/17f96065/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> End of rspec-users Digest, Vol 28, Issue 87
> *******************************************