Forum: RSpec How to kill a running spec

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Nick H. (Guest)
on 2008-11-16 21:42
(Received via mailing list)
Hi guys. Occasionally, I'll want to kill a long spec process that's
running. Usually I hit CTRL+c to kill a running process, but doing
that for a running spec just causes "^C" to be printed to the
terminal, and whichever spec example was running to fail.

I've also tried using /bin/kill to kill the spec process, but that
just causes whichever spec example was running to catch a
SignalException, and fail.

Any suggestions for how to do this? Thanks,
Nick
Pat M. (Guest)
on 2008-11-16 22:30
(Received via mailing list)
I just hold ctl+c until it quits out.

Pat
Nick H. (Guest)
on 2008-11-16 23:21
(Received via mailing list)
On 2008-11-16, at 15:21, Pat M. wrote:
> I just hold ctl+c until it quits out.
>
> Pat

Hahha, brute force it, eh?
Scott T. (Guest)
on 2008-11-17 00:48
(Received via mailing list)
On Nov 16, 2008, at 2:40 PM, Nick H. wrote:

> Hi guys. Occasionally, I'll want to kill a long spec process that's
> running. Usually I hit CTRL+c to kill a running process, but doing
> that for a running spec just causes "^C" to be printed to the
> terminal, and whichever spec example was running to fail.
>
> I've also tried using /bin/kill to kill the spec process, but that
> just causes whichever spec example was running to catch a
> SignalException, and fail.

What signal are you sending?  Is it a kill -9 (a KILL, a TERM, ...?)?

Scott
Camilo C. (Guest)
on 2008-11-17 00:57
(Received via mailing list)
Hello,

I'm specing a controller, but having trouble getting my head around
what I've created.

I'm specing a products controller for an admin user. Two before
filters check the user is logged in and authorized.
A logged-in user only has admin privileges within her own subdomain.
So, sarah, when logged in
can only administer products at sarah.mysite.com/admin/products.

Since there are two account types that require authentication
(supplier and customer),
the user model is polymorphic:

class User
  belongs_to :allowable,  :polymorphic => true
   ...
end

class Supplier
  has_many :users, :as => :allowable
end


class Customer
  has_one  :user, :as => :allowable
end

A supplier has their own subdmain (sarah.mysite.com) and a customer
has a profile page at mysite.com/people/joe.

When sarah is logged-in, I check she has permission to edit content at
sarah.mysite.com with:

def authorized_resource?(resource)
   current_user.allowable == resource
end

'resource' being a supplier or customer object.

My mind is failing me trying to describe Admin::ProductsController:

http://pastie.org/316414

Both examples pass, but I'm not sure I understand exactly what I'm
doing. In particular, can I make:

it "should send unauthorized user to home page" do
   controller.should_receive(:authorized_resource?).and_return false
   do_get
   response.should redirect_to(home_path)
end


pass without stubbing the false return. How can I set up the mock
instances, so that the controller method
'authorized_resource?' actually returns a false method. Any guidance
would be much appreciated.

many thanks

Omar
Zach D. (Guest)
on 2008-11-17 01:15
(Received via mailing list)
On Sun, Nov 16, 2008 at 5:53 PM, Sahyoun <removed_email_address@domain.invalid> 
wrote:
>
>        has_many :users, :as => :allowable
> When sarah is logged-in, I check she has permission to edit content at
> sarah.mysite.com with:
>
> def authorized_resource?(resource)
>  current_user.allowable == resource
> end

I would probably change this method so you are pushing the
responsibility onto your user. For example, I might change the
authorized_resourced method to look like:

def authorized_resource?(resource)
    current_user.can_access?(resource)
end

Now in your example you can stub/expect the interaction with the user
object. Pushing this  decision for who can access what really should
stay out of your controller. Even though the authorization check is
quite simple right now (ie: user.allowable == resource) this puts more
logic in your controller, makes it slightly harder to test and also
re-use.

Hope this helps,

Zach

> it "should send unauthorized user to home page" do
>
> many thanks
>
> Omar
>
>
> _______________________________________________
> rspec-users mailing list
> removed_email_address@domain.invalid
> http://rubyforge.org/mailman/listinfo/rspec-users
>



--
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com
Nick H. (Guest)
on 2008-11-17 18:55
(Received via mailing list)
On 2008-11-16, at 17:46, Scott T. wrote:
> What signal are you sending?  Is it a kill -9 (a KILL, a TERM, ...?)?
>
> Scott

I've just been running it as ``kill 12345''. I stay away from -9, as
it's a pretty harsh thing to do. I haven't tried other signals though,
so I should give them a whirl and report back if any of them succeed
in killing the entire spec process.
-Nick
Camilo C. (Guest)
on 2008-11-19 11:56
(Received via mailing list)
Thanks Zach,

Your suggestion has put me back on track.

Cheers,
Omar
This topic is locked and can not be replied to.