This is exactly correct.
Tests should be verbose. They should not be DRY (don't repeat
yourself). Code reuse should be minimal.
The reason is because you are testing the possible outcomes. If your
inputs are variable, your outcomes are variable. Testing that you can
iterate over an array of things and get those things back out is
testing that the programming language works, not that the recipes
you're writing are doing what you want.
If you have an attribute that defines a list of packages, and you have
a recipe that iterates over that list creating package resources, you
should very well expect that Chef works, and will install each of
those packages. That is to say, the scenario you describe is testing
that Ruby and Chef work. Because both projects are very well tested,
we know that to be true.
A more valuable test in your post convergence is that the outcome of
having the package(s) installed is correct. If I install the `zsh` and
`vim` packages, I want to make sure that `zsh` is a valid, available
shell for my login users, and that `vim` is a valid executable program
in my $PATH.
The cycle of creating a machine, installing and running chef on it,
and then performing the test that the packages are there is very time
consuming for this purpose. I think you'd better spend your time
writing ChefSpec tests, rather than Serverspec tests, to verify this:
"if I set the attribute to have package zsh and vim, then I expect
those resources to exist." This is slightly ow value because again,
you're testing that Ruby works. However, it does protect you against
regressions in case the attribute name is changed, so input validation
is good, since Ruby is weakly typed.
These blog posts by Seth Vargo are great and chock full of information:
* https://sethvargo.com/unit-testing-correctly/
* https://sethvargo.com/unit-testing-chef-cookbooks/
This post by Andrew Crump about post-convergence testing is pretty
solid, though a bit old in terms of specific tools and implementation:
* https://www.chef.io/blog/2012/07/20/on-the-level-testing-your-infrastructure/
And finally, I wrote this post recently discussing all the various
facets of testing infrastructure with Chef:
* https://www.chef.io/blog/2015/04/21/overview-of-test-driven-infrastructure-with-chef/
Hope this helps,
Joshua
On Tue, May 12, 2015 at 5:03 PM, Cassiano Leal < "> > wrote:
> The “weird pseudocodey language used by RSpec” is called Ruby, and it’s
> definitely not pseudo in any sense. :)
>
> It’s true that RSpec implements a DSL on top of Ruby, very much like Chef
> itself. It’s still 100% Ruby in both cases though.
>
> Now, about your specific problem, I don’t think there is a way to do what
> you want.
>
> In any case, ask yourself if you really need to test that the packages are
> installed. If the package provides a service, you can make ServerSpec verify
> that the service is running (it’s got a resource for that), or that a
> certain port has a listening TCP socket or something else. Think about the
> actual functionality you want to assert instead of the method used to put it
> there.
>
> If you still see value in testing that specific packages were installed,
> then I guess you’ll have to be explicit in your tests as well as on the
> code.
>
> --
> Cassiano Leal
>
>
> On 12 May 2015 at 22:18:51, Fabien Delpierre ( "> )
> wrote:
>
> Hi folks,
> I'm new to Test Kitchen and trying to make sense of it all. I'm also new to
> TDD (and programming in general) so the weird pseudocodey language used by
> RSpec messes with my head because I'm expecting code and it reads more like
> English.
> Anyway.
> Right now I'd like to see if I can use one of my nodes' attributes to run
> tests.
> Specifically, I have something like this:
>
> attributes/default.rb:
> case node['platform']
> when 'centos'
> default['myrecipe']['packages'] = %w(package1 package2)
> when 'ubuntu'
> default['myrecipe']['packages'] = %w(package3 package4)
> end
>
> recipes/default.rb:
> node['myrecipe']['packages'].each do |pkg|
> package pkg
> end
>
> Now, in my tests, what I'd like is to do something like:
>
> node['myrecipe']['packages'].each do |pkg|
> describe package(pkg) do
> it { should be_installed }
> end
> end
>
> I can do something like this (note I haven't tested it because I'm done for
> today but I looked at other people's code on GitHub and found similar
> things, so I imagine that it works):
> case os['family']
> when 'centos'
> packages = %w(package1 package2)
> when 'ubuntu'
> packages = %w(package3 package4)
> end
>
> packages.each do |pkg|
> describe package(pkg) do
> it { should be_installed }
> end
> end
>
> So assuming this works, that's nice, but it requires maintaining on top of
> the list of attributes in the attributes/default.rb file, hence my wondering
> whether there is a way for Kitchen to grab those values off the cookbook.
> Because that would be more efficient.
>
> Is that possible? Or am I doomed?
>
Archive powered by MHonArc 2.6.16.