Lackluster type coercion

[conorsch]

As of v0.10.1, the following inspec test fails:

describe port('5555') do
  it { should be_listening }
end

with the traceback:

  1) Port  5555 should be listening
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
       expected `Port  5555.listening?` to return true, got false
     # ./test/integration/default/riemann_server_spec.rb:63:in `block (2 levels) in load'
     # /home/conor/.gem/ruby/2.1.0/gems/inspec-0.10.1/lib/inspec/runner_rspec.rb:55:in `run'
     # /home/conor/.gem/ruby/2.1.0/gems/kitchen-inspec-0.11.0/lib/kitchen/verifier/inspec.rb:43:in `call'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:405:in `block in verify_action'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:495:in `call'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:495:in `synchronize_or_call'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:460:in `block in action'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:459:in `action'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:401:in `verify_action'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:348:in `block in transition_to'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:347:in `each'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:347:in `transition_to'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:160:in `verify'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/command.rb:176:in `public_send'
     # /home/conor/.gem/ruby/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/command.rb:176:in `block (2 levels) in run_action'

However, this inspec test passes just fine:

describe port(5555) do
  it { should be_listening }
end

The only difference is whether a string or an int was passed to the function. Surely the library can learn to accommodate inputs of both types and treat them accordingly. Admittedly, the port docs do provide examples with ints, rather than strings, but overall this is the type of decision a machine can make fine, and it will doubtless frustrate first-time users of the project.

Assuming updating the code would be problematic, because it'd be hard to use numeric comparison operators, at least some documentation about the importance of types would be helpful.

[arlimus]

+1 :)

this looks like a theme that'll come up more often; we have recently introduced a fantastic helper at the other end of the equation: #318 . So this issue covers input, which the resource would have to consider itself; but if we create something that other people can use, including we can use on our resources, to make these cases easier, that'd be helpful.

there's also the other view, which could warn you about using integers instead of strings. Like a linter for these cases.

Let's check which is more user-friendly and less confusing in the end.

[arlimus]

Now works as intended. Tested in InSpec v1.21