It's hard to see the value of TDD at the beginning. But trust me...it saves SO MUCH PAIN once you're working with a long lived code base.I gave a talk on this (with examples in Rspec, through for a Rails code base) called "Test Driven Development: A Love Story" a couple of years ago http://confreaks.tv/videos/acr2013-test-driven-development-a-love-storyIt's about how I passed through the five stages of grief in learning TDD and how that grief turned to both sanity with the code bases I maintain and re-ignited my love of programming.On Thu, May 14, 2015 at 6:10 AM, Fabien Delpierre < " target="_blank"> > wrote:So, essentially I'm wasting my time / doing it wrong? :)That's OK, all these concepts are pretty foreign to me at this point, I was only introduced to TDD fairly recently and still don't really understand. For me, as a beginner programmer, it seems like it made the learning curve twice as steep, and doubled the time I spend coding, with no clear benefit other than pleasing people who expect me to produce tests. I'll read the blog posts you mentioned, thank you for your detailed answer!On Wed, May 13, 2015 at 1:03 AM, Joshua Timberman < " target="_blank"> > wrote: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 < " target="_blank"> > 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 ( " target="_blank"> )
> 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?
>
--Nell Shamrell-Harrington — Software Engineer
206.745.0000 – " target="_blank"> – my: LinkedIn Twitter
CHEF
TM
chef.io Blog Facebook Twitter Youtube
Archive powered by MHonArc 2.6.16.