rspec-puppet matchers are defined for tests which exist in
spec/functions, but the function unit tests lived in
spec/unit/puppet/parser/functions. This moves them to the correct place
for using rspec-puppet
The module PuppetlabsSpec::PuppetSeams has been renamed in the
puppetlabs_spec_helper gem to PuppetlabsSpec::PuppetInternals.
The method to obtain a scope object has also changed slightly. Without
this patch the spec tests will fail because the stdlib module is not
aligned with the spec helper gem. This patch fixes the problem by
matching up messages with their receivers in the spec helper library.
Paired-with: Andrew Parker <andy@puppetlabs.com>
Without this patch all of the spec tests for parser functions in stdlib
would instantiate their own scope instances. This is a problem because
the standard library is tightly coupled with the internal behavior of
Puppet. Tight coupling like this creates failures when we change the
internal behavior of Puppet. This is exactly what happened recently
when we changed the method signature for the initializer of
Puppet::Parser::Scope instances.
This patch fixes the problem by creating scope instances using the
puppet labs spec helper. The specific method that provides scope
instances in Puppet-version-independent way is something like this:
let(:scope) { PuppetlabsSpec::PuppetSeams.parser_scope }
This patch simply implements this across the board.
This time around I actually know why I'm doing this thanks to the
reminder from Nick Lewis.
Ruby will replace itself in memory with the executable listed in the
interpreter line if the string "ruby" is not in there.
Since /usr/bin/env rspec doesn't contain the substring "ruby", you can't
actually run ruby -W1 or whatever on the file.
This patch fixes the problem by making sure "ruby" is present,
preventing ruby from replacing itself in memory.
This patch adds an optional "step" argument to the stdlib range()
function. There is no change to the default behavior of the function;
however, passing a numeric "step" argument invokes the Ruby Range#step
method, e.g.
range("0", "9", "2")
returns
[0,2,4,6,8]
Without this patch the specified behavior of strings that are numeric
only and zero padded is unclear and untested in the spec tests. This is
a problem because it's not clear that range('00', '10') will actually
return [ "0", "1", ..., "10" ] instead of [ "00", "01", ..., "10" ]
This patch addresses the issue by providing explicit test coverage. If
the string conversion behavior of puppet changes, this test will begin
to fail.
