I have a plugin that uses RSpec, and it's being used by a Rails app that
does not otherwise use RSpec (and does not want to).
I can install the RSpec gem, but of course there is no RSpec-on-Rails
gem. And I wouldn't really want to include the whole rspec-on-rails
plugin inside my plugin, even
On Oct 23, 2007, at 6:32 PM, David Chelimsky wrote:
> On 10/23/07, Jonathan Linowes <[EMAIL PROTECTED]> wrote:
>> "app" is short for "application",
>> "lib" is short for "library"
>> so why not shorten "behavior" to something like "beh" or "behav"
>> (also avoids the 2 english spellings)
>>
>> /b
I've been wondering the same for quite a while
http://www.nabble.com/simple-story,-extract-link-t4518721.html
but hadnt asked the question so succinctly
In that thread, Pat suggests helpers like click_link and submit_form
If you progress along these lines, please post your solution, I'm
very int
I'm having a lot of trouble understanding why stories are nice for me
as a programmer? It seems targeted towards people who don't want to
write code. Generally speaking, I don't see the need for that on the
projects I'm working on.
Is it possible for this to be a separate library from RSpec so tha
On 10/24/07, John W. Long <[EMAIL PROTECTED]> wrote:
> I'm having a lot of trouble understanding why stories are nice for me
> as a programmer? It seems targeted towards people who don't want to
> write code. Generally speaking, I don't see the need for that on the
> projects I'm working on.
>
I s
Hi,
Thought this might be of interest story writers.
The mechanize plugin seems to play nice with RSpec.
The following mix of methods seems to work just fine.
I especially like the helpers for populating forms.
agent = WWW::Mechanize.new
page = agent.get 'http://www.gmail.com'
page.should have_t
I'm trying to stub(!) the Kernel.` (backquote) method and I'm having
confusing (to me) results. Here's the method I'm spec'ing:
class Barcode
...
def raw_barcodes
self.make_temporary_copy
`OcrBarcode #{self.temp_file_path}`
end
...
end
And this is my (newbish) attempt at the spec:
On Oct 24, 2007, at 2:58 AM, Scott Taylor wrote:
Is no one else experiencing roll back problems on Trunk rspec?
Scott
>
> On Oct 23, 2007, at 1:54 PM, David Chelimsky wrote:
>
>> On 10/23/07, sinclair bain <[EMAIL PROTECTED]> wrote:
>>> Oops,
>>>
>>> A bit over-zealous on the send.
>>>
>>> As
On 10/24/07, John W. Long <[EMAIL PROTECTED]> wrote:
> I'm having a lot of trouble understanding why stories are nice for me
> as a programmer? It seems targeted towards people who don't want to
> write code. Generally speaking, I don't see the need for that on the
> projects I'm working on.
1. If
I found an alternate route, which may or may not work for others.
Instead of using Kernel#` (backquote / backtick), you might be able to
use Kernel#system. The difference:
Kernel#` returns the standard output of running the command in a subshell
Kernel#system returns true if the command was fou
On Oct 24, 2007, at 6:39 pm, Pat Maddox wrote:
> 4. Stories enable better refactoring. Using mocks makes your object
> specs more brittle, so changes to your code often requires changes to
> the specs. Because stories work at a very high level, specifying
> observable behavior of the system, yo
On Oct 24, 2007, at 6:07 am, David Chelimsky wrote:
> The following only affects people who have bravely begun to experiment
> with the 2 day-old plain text story runner and definable groups of
> steps.
Ok, *now* I'm allowed to say that following trunk is a rollercoaster ;o)
--
blog @ http:
On Oct 24, 2007, at 6:07 am, David Chelimsky wrote:
> steps = StepGroup.new do
> steps do |define|
> define.given(...) {...}
> end
> end
I'm using "interpret", eg (without blocks)
steps = Spec::Story::StepGroup.new do |interpret|
interpret.given "an engine for dialect: $dialect"
i
On 10/24/07, Ashley Moran <[EMAIL PROTECTED]> wrote:
>
> On Oct 24, 2007, at 6:07 am, David Chelimsky wrote:
>
> > The following only affects people who have bravely begun to experiment
> > with the 2 day-old plain text story runner and definable groups of
> > steps.
>
>
> Ok, *now* I'm allowed to
On 10/24/07, Andy Watts <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Thought this might be of interest story writers.
> The mechanize plugin seems to play nice with RSpec.
> The following mix of methods seems to work just fine.
> I especially like the helpers for populating forms.
>
> agent = WWW::Mechan
On 10/24/07, James Hughes <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Andy Watts <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Thought this might be of interest story writers.
> > The mechanize plugin seems to play nice with RSpec.
> > The following mix of methods seems to work just fine.
> > I espe
Ok, this is INCREDIBLY finicky of me, and I'm a really finicky person
at the best of times, but I noticed that when you use the TM
Alternate File command to create specs, it does it with a header line
like this:
File.dirname(__FILE__) + '/../../../spec_helper'
I use a header line like th
On Oct 24, 2007, at 10:34 pm, Ashley Moran wrote:
> Does the former expose you to loading the spec_helper twice under any
> circumstances?
I answered my own question - autotest will barf if it is forced to
require something twice that shouldn't be. As it happens, it's the
facets monkey-patc
Hi
I'm loading a gem on demand but can't find a way to spec it.
Assuming rubygems is already loaded, I assumed the following would work:
describe SqliteConnection, " class" do
it "should require 'sqlite3'" do
Kernel.should_receive(:require).with("sqlite3")
SqliteConnection.
Hi
Has anyone mocked a call like the following for backgroundrb?
MiddleMan.new_worker(:class => :admin_email_worker, :args => params
[:email])
I cannot seem to find the correct manner to do it.
Would have liked to be able to do MiddleMan.should_receive
(:new_worker).with(:class => :admi
Okay, I give up. I have been trying to set session values in a controller,
but no matter what, once the request is made and inside the controller,
the session is empty. What's the correct way? I have tried
session['whatever'] = something
controller.stub!(:session).and_return(session)
I tried crea
I have some specs that run just fine using "rake spec:controllers" or
"script/spec spec/controllers" but if I run "script/spec spec/controllers
-X" with the spec server running, I end up getting some mocks that fail
saying expected once, and being called twice. Any ideas what would cause
this kind
On 10/24/07, Shane Mingins <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> Has anyone mocked a call like the following for backgroundrb?
>
> MiddleMan.new_worker(:class => :admin_email_worker, :args => params[:email])
>
> I cannot seem to find the correct manner to do it.
>
> Would have liked to be able to d
i've done this in controller specs
session[:whatever] = something
do_it
--linoj
On Oct 24, 2007, at 9:06 PM, Steve wrote:
> Okay, I give up. I have been trying to set session values in a
> controller,
> but no matter what, once the request is made and inside the
> controller,
> the session
On Oct 24, 2007, at 9:03 PM, Steve wrote:
> I have some specs that run just fine using "rake spec:controllers" or
> "script/spec spec/controllers" but if I run "script/spec spec/
> controllers
> -X" with the spec server running, I end up getting some mocks that
> fail
> saying expected once, a
On Wed, 24 Oct 2007 21:36:15 -0400, Scott Taylor wrote:
>
> Did you try restarting the drb server?
>
> Scott
Yes. Multiple times. Exact same results each time.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinf
On Wed, 24 Oct 2007 21:29:39 -0400, Jonathan Linowes wrote:
> i've done this in controller specs
>
> session[:whatever] = something
> do_it
>
Yeah, I did that, and it was turning up nil when I actually made the
request.
___
rspec-users mailing list
r
RubyGems does indeed muck with the "require" method.
I believe the current version uses the "gem" method and deprecates the
"require" method. Rails warns me about something to that effect whenever I run
script/server, anyway.
Not that I seem to have given you any real help with your spec quest
On Oct 24, 2007, at 9:53 PM, Steve wrote:
> On Wed, 24 Oct 2007 21:36:15 -0400, Scott Taylor wrote:
>>
>> Did you try restarting the drb server?
>>
>> Scott
>
> Yes. Multiple times. Exact same results each time.
Well, I guess you'll probably need to give us the following:
What versions of the f
Okay - so the sqlite bug reported a day or so ago on the list is real
bug. I'm going to file something in the tracker for that...
I also learned that before(:all)...after(:all) is not wrapped in a
transaction, the way before(:each)...after(:each) is. Is there some
reason behind this? Can
I'm playing with step implementations that use hpricot to manipulate
response.body.
Here's what I have so far.
Very much work-in-progress, but may be of some use to you.
#This step implementation takes a button's label, collects the inputs and
does the POST/PUT
add.when("I click the $button_tex
On 10/24/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> Okay - so the sqlite bug reported a day or so ago on the list is real
> bug. I'm going to file something in the tracker for that...
>
> I also learned that before(:all)...after(:all) is not wrapped in a
> transaction, the way before(:each)..
The following works:
it "should evaluate a passed in block in the context of the
interview object" do
block = Proc.new { raise unless self.is_a?
(Interview) }.should_not raise_error
Interview.create(:title => "Text", &block)
end
However, the following does not:
it "should e
On Oct 25, 2007, at 12:40 AM, David Chelimsky wrote:
> On 10/24/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>>
>> Okay - so the sqlite bug reported a day or so ago on the list is real
>> bug. I'm going to file something in the tracker for that...
>>
>> I also learned that before(:all)...after(:a
On 10/24/07, Evan David Light <[EMAIL PROTECTED]> wrote:
> The following works:
>
>it "should evaluate a passed in block in the context of the
> interview object" do
> block = Proc.new { raise unless self.is_a?
> (Interview) }.should_not raise_error
> Interview.create(:title => "Text"
I just updated to r2784, and now all of my specs output the '.' and then
'WARNING: there is already a transaction in progress', either once or
twice before the next dot. It's indicating that all specs are passing,
there's just a whole ton of noise for some reason. Any idea what causes
this to be t
What's the current best practice for spec'ing (and stubbing) RJS?
response.should have_rjs(*args, &block) from rspec_on_rails works well
for things that
assert_select_rjs supports. But for other things, like say
page[:elm].add_class_name :class_name, it's not clear to me the best
way to test for t
On 10/24/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> Okay - so the sqlite bug reported a day or so ago on the list is real
> bug. I'm going to file something in the tracker for that...
This should be fixed in trunk now. Please report back.
___
rspec
38 matches
Mail list logo
