On 8/17/07, Cody P. Skidmore <[EMAIL PROTECTED]> wrote:
>
> I found documentation on Runner & calling Spec on the command line. I'm
> able to run it on multiple models or a single one and format the output as
> HTML now. Previously I used the Rake task expecting it to behave the same
> way passin
On 8/17/07, Courtenay <[EMAIL PROTECTED]> wrote:
> That's exactly my point; enforcing the difference between
> should_receive vs stub!
Great convention, but I think making the tool enforce it is a bit restrictive.
> On 8/17/07, Lance Carlson <[EMAIL PROTECTED]> wrote:
> > what about template.shou
I found documentation on Runner & calling Spec on the command line. I'm
able to run it on multiple models or a single one and format the output as
HTML now. Previously I used the Rake task expecting it to behave the same
way passing --format html:path/to/file.html or setting it somehow in
spec.op
> thats pretty much what I thought, I'll give it a push around and e-
> mail back the results
cool - good luck ...I'm off to bed as it's 1am here in the UK but I'm
sure one of the useful chaps round here 'll help you out with any probs
btw, I just noticed I've put @ticket_params = {} in the be
thats pretty much what I thought, I'll give it a push around and e-mail back
the results
On 8/17/07, rupert <[EMAIL PROTECTED]> wrote:
>
> Not entirely sure how to go about mocking the association, but it's going
> to be something along these lines (totally untested!)
>
> describe TicketsContr
Not entirely sure how to go about mocking the association, but it's
going to be something along these lines (totally untested!)
describe TicketsController, "handling POST /tickets" do
before do
@ticket = mock_model(Ticket, :save => true)
@user_tickets_association = mock("accociat
That makes a-lot of sense. That 'new' word threw me off.
My create method is slightly more complex and I'm not sure how to spec it.
def create
@user = User.find(params[:user_id])
@ticket = @user.tickets.build(params[:ticket])
if @ticket.save
redirect_to tickets_path
else
what's in the create method of the controller?? you've only given the
contents of the new method - and without knowing what you want it to
do it's hard to know what will work.
Assuming it's the normal
def create
@ticket = Ticket.new(params(:ticket])
if @ticket.save
etc etc
end
the
def create (not de create)
On 8/17/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> Sorry - totally missed the controller code in your first example.
> You're posting to create, not new:
> de create
> Ticket.new
> end
>
> That should do the trick.
>
>
> On 8/17/07, Andrew WC Brown <[EMAIL PROTEC
Sorry - totally missed the controller code in your first example.
You're posting to create, not new:
de create
Ticket.new
end
That should do the trick.
On 8/17/07, Andrew WC Brown <[EMAIL PROTECTED]> wrote:
> I replaced:
>
> @ticket.should_receive(:new).with(@params).and_return(@ticket)
>
> wi
I replaced:
@ticket.should_receive(:new).with(@params).and_return(@ticket)
with
Ticket.should_receive(:new).with(@params).and_return(@ticket)
Similar Error
1)
Spec::Mocks::MockExpectationError in 'TicketsController handling POST
/tickets should create a new ticket'
Mock 'Class' expected :new w
I agree :)
On 8/17/07, Courtenay <[EMAIL PROTECTED]> wrote:
> That's exactly my point; enforcing the difference between
> should_receive vs stub!
>
> On 8/17/07, Lance Carlson <[EMAIL PROTECTED]> wrote:
> > what about template.should_receive(:current_user)?
> >
> > I don't know if that's a bad ide
That's exactly my point; enforcing the difference between
should_receive vs stub!
On 8/17/07, Lance Carlson <[EMAIL PROTECTED]> wrote:
> what about template.should_receive(:current_user)?
>
> I don't know if that's a bad idea to do that in the before(:each) but
> it's more convenient..
>
> On 8/17
what about template.should_receive(:current_user)?
I don't know if that's a bad idea to do that in the before(:each) but
it's more convenient..
On 8/17/07, Courtenay <[EMAIL PROTECTED]> wrote:
> What do you guys think of this: if someone calls should_receive
> outside of an "it" block, it warns y
What do you guys think of this: if someone calls should_receive
outside of an "it" block, it warns you.
before(:each) do
@foo = Foo.new
@foo.should_receive(:monkeys)
end
would warn you that you're setting an expectation in the wrong place,
and that "stub" is correct when setting up ob
Greetings everyone. I'm learning RSpec and am pretty fresh to Ruby/Rails,
but am so excited I can't help jumping in. I'm running before I can walk
here. :-)
Yesterday I tried outputting test results to HTML instead of colorized
plain text. It looked like there were some entries in the change l
This is a test. I sent an email to the list earlier but it looks like no
one received it...
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On 8/17/07, Andrew WC Brown <[EMAIL PROTECTED]> wrote:
> I've been off the rspec for a few months and I'm trying to get back on it.
>
> 1)
> Spec::Mocks::MockExpectationError in 'TicketsController
> handling POST /tickets should create a new ticket'
> Mock 'Ticket_1001' expected :new with ({}) on
I've been off the rspec for a few months and I'm trying to get back on it.
1)
Spec::Mocks::MockExpectationError in 'TicketsController handling POST
/tickets should create a new ticket'
Mock 'Ticket_1001' expected :new with ({}) once, but received it 0 times
./spec/controllers/tickets_controller_sp
Hello,
I am getting a 'No route matches' error in rspec with routes that have a
path_prefix composed by map.with_options. Rails recognizes the routes just
fine and the site works, but I can't get the specs to pass unless I put the
prefix in each individual route. Any help is appreciated.
My foo m
On 8/17/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> On Aug 17, 2007, at 2:59 AM, David Chelimsky wrote:
>
> > On 8/16/07, Joe Van Dyk <[EMAIL PROTECTED]> wrote:
> >> I don't like this:
> >>
> >> i = mock(Integer)
> >> i.should_receive(:asdfasdf).and_return('foo')
> >> puts i.asdfasd
On Aug 17, 2007, at 2:59 AM, David Chelimsky wrote:
> On 8/16/07, Joe Van Dyk <[EMAIL PROTECTED]> wrote:
>> I don't like this:
>>
>> i = mock(Integer)
>> i.should_receive(:asdfasdf).and_return('foo')
>> puts i.asdfasdf
>>
>>
>> Shouldn't rspec check to see that :asdfasdf is a valid me
On 8/16/07, Steve Tooke <[EMAIL PROTECTED]> wrote:
> Hmm that's true.
>
> If the acts_as_list implementation changed, or is removed then this
> isn't going to work. But you don't really want to go down the rabbit
> warren of checking that the whole of the acts_as_list implementation
> works as expe
On 8/16/07, Joe Van Dyk <[EMAIL PROTECTED]> wrote:
> I don't like this:
>
> i = mock(Integer)
> i.should_receive(:asdfasdf).and_return('foo')
> puts i.asdfasdf
>
>
> Shouldn't rspec check to see that :asdfasdf is a valid message to be
> sending Integer?
Put simply: no. That's what inte
24 matches
Mail list logo
