I wrote a custom chef handler to execute some rspec tests:
class Handler < ::Chef::Handler
def report
…
result = RSpec::Core::Runner.run(existing_test_files)
…
end
…
end
Is it possible to access the attributes of the current chef run in these
rspec-tests? And when, how?
And if its not possible: Can I get the node or environment of the current chef
run in these rspec-tests? Then I would parse it’s jsonfile… .
I don't recommend this approach, because you're conflating the
variables of the system under test with the test vectors, so how do
you know if you have a valid test?
However, that said, this is the approach that the Chef Minitest
Handler takes, so you might want to check that out.
I wrote a custom chef handler to execute some rspec tests:
class Handler < ::Chef::Handler
def report
...
result = RSpec::Core::Runner.run(existing_test_files)
...
end
...
end
Is it possible to access the attributes of the current chef run in these
rspec-tests? And when, how?
And if its not possible: Can I get the node or environment of the current chef
run in these rspec-tests? Then I would parse it's jsonfile.. .
Is it possible to access the attributes of the current chef run in
these rspec-tests? And when, how?
Julian C. Dunn responded:
I don't recommend this approach, because you're conflating the
variables of the system under test with the test vectors, so how do
you know if you have a valid test?
What do others recommend doing to verify, for example, that use of a
recipe results in a file existing in a location described in a node
attribute? The recipe I want to test includes golang::default,
downloads some source code, then creates files in a subdirectory of
node['go']['gopath'].
I'm considering these options:
Hard-coding the default values of applicable node attributes
in my serverspec tests
Overriding the attributes in .kitchen.yml and hard-coding the
override values in my tests
Overriding the attributes in .kitchen.yml and hard-coding the
override values in my tests
This provides a more 'stable' approach of stating with some determinism
that when providing some attributes at an input, the cookbook behaves in a
known manner.
If you need to test multiple outcomes, add more suites with different
attributes.
Is it possible to access the attributes of the current chef run in
these rspec-tests? And when, how?
Julian C. Dunn responded:
I don't recommend this approach, because you're conflating the
variables of the system under test with the test vectors, so how do
you know if you have a valid test?
What do others recommend doing to verify, for example, that use of a
recipe results in a file existing in a location described in a node
attribute? The recipe I want to test includes golang::default,
downloads some source code, then creates files in a subdirectory of
node['go']['gopath'].
I'm considering these options:
Hard-coding the default values of applicable node attributes
in my serverspec tests
Overriding the attributes in .kitchen.yml and hard-coding the
override values in my tests
[Dumping attributes with a helper cookbook][1], then loading
the result in my tests
Figuring out where the "property" hash in the [apache2
cookbook's tests][2] comes from and doing something similar
Is it possible to access the attributes of the current chef run in
these rspec-tests? And when, how?
Julian C. Dunn responded:
I don't recommend this approach, because you're conflating the
variables of the system under test with the test vectors, so how do
you know if you have a valid test?
What do others recommend doing to verify, for example, that use of a
recipe results in a file existing in a location described in a node
attribute? The recipe I want to test includes golang::default,
downloads some source code, then creates files in a subdirectory of
node['go']['gopath'].
I'm considering these options:
Hard-coding the default values of applicable node attributes
in my serverspec tests
Overriding the attributes in .kitchen.yml and hard-coding the
override values in my tests
[Dumping attributes with a helper cookbook][1], then loading
the result in my tests
Figuring out where the "property" hash in the [apache2
cookbook's tests][2] comes from and doing something similar
The property hash comes from the per platform fixtures
at test/fixtures/platforms. They are per platform static attributes.
I would have just used the ones in .kitchen.yml, but with needing to test
permutations on each of the platforms, having
several suites would make it way to complex. The idea came from serverspec ( Serverspec - Advanced Tips),
I just applied it to chefspec as well.