Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions core/signal/signame_spec.rb
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
require File.expand_path('../../../spec_helper', __FILE__)

describe "Signal.signame" do
it "takes a signal name with a well known signal number" do
Signal.signame(0).should == "EXIT"
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should wrap this spec with:

platform_is_not :windows do

as I think these numbers are POSIX-specific.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also possible to use Signal.list to avoid hard-coding numbers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to depend on Signal.list.
But, It's not strong opinion.
I'll use Signal.list.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's a trade-off. If the numbers are portable on POSIX platforms, it's OK to use hardcoded numbers.


ruby_version_is "2.0"..."2.3" do
it "raises an ArgumentError if the argument is an invalid signal number" do
lambda { Signal.signame(-1) }.should raise_error(ArgumentError)
end
end

ruby_version_is "2.3" do
it "returns nil if the argument is an invalid signal number" do
Signal.signame(-1).should == nil
end
end

it "raises a TypeError when the passed argument can't be coerced to Integer" do
lambda { Signal.signame("hello") }.should raise_error(TypeError)
end
end