I'd suggest to look at this in a different way. Creating test (or
_test) recipes you can create test scenarios for your lwrp to pass (or
I have several cookbooks that exhibit this behavior such as
GitHub - scottmlikens/diamond: Chef Cookbook for deploying Diamond and GitHub - scottmlikens/carbon: un-pattern of deploying carbon (cache/relay), see https://github.com/damm/graphite for counterpart. for
example. Testing to make sure your cookbook compiles is great, making
sure it does what you want, fantastic.
Testing the ways you use the cookbook (or don't use it) is even better.
As an early adopter of Chef, let alone testing my Chef Cookbooks I can
tell you it's made my life a whole lot easier. It's not a far stretch
to do write your tests before your cookbook.
P.S. if your worried about pollution or creating cruft, look at your
tests as examples of how to use your LWRP.
On 5/1/13 10:30 AM, Bryan Stenson wrote:
As described, I'm hoping to NOT have any testing recipes exist to be
assigned to a node's run_list. The purist in me rejects the idea that
I have to have a recipe ("_test.rb", in your example) just to test my
Having said that, I'm open to suggestions. Maybe my resistance to an
"only used for testing recipe" is misguided or uninformed. If so, I'd
like to hear why.
On Wed, May 1, 2013 at 9:54 AM, John Dewey <email@example.com
You test it like anything else. A trivial example:
On Wed, May 01, 2013 at 09:49:49AM -0700, Bryan Stenson wrote:
> An empty default recipe, I suppose, I understand.
> But, I think ":step_into => ['foo']" only ALLOWS the
> descend into the "foo" provider...it doesn't actually
exercise it (how
> would it know the parameters to test?!)
> At this point, I think I'm planning on copying the entire
> a "temp" directory, applying "fixture recipes" to the copy, and
> pointing the ChefRunner to that directory as the :cookbook_path
> This will allow me to write "fixture recipes" for testing,
> them out of the actual recipe folder (so they're unable to be
used in a
> If/when I get something worthy of sharing, I will.
> On Wed, May 1, 2013 at 9:38 AM, Mike <firstname.lastname@example.org
> John is right - it's becoming common to provide an empty
> for a cookbook that doesn't have any recipes.
> On Wed, May 1, 2013 at 12:34 PM, John Dewey <email@example.com
> > I believe you can simply create an empty default.rb,
> > and "step into" the LWRP you wish to test.
> > John
> > On Wed, May 01, 2013 at 10:12:18PM +0545, millisami r wrote:
> >> +1
> >> I m too kinda similar situation.
> >> On Wednesday, May 1, 2013, Bryan Stenson wrote:
> >> Ohai!
> >> Following the cookbook pattern described in the
> >> trying to create a library cookbook which contains some
> >> This library cookbook will not have any meaningful
recipe on its
> >> own...it will only supply providers and resources to be
> >> application cookbooks.
> >> I'd like to test the library cookbook separately, and I
> >> is the correct approach for unit testing. I see that
> takes a
> >> recipe list when "converging", but, since my library
> >> have recipes, I don't have one to give to ChefRunner.
> >> I suppose I'd like some suggestions/experiences on how
> >> From my perspective, I can see at least two ways to
> (with a
> >> STRONG preference on the latter):
> >> 1. Create a "lwrp_testing.rb" recipe which will
> >> to each LWRP the library cookbook provides. I don't
> >> then I've got a testing recipe floating around which
> >> to a node in production - and that's just silly. I
> >> recipe with a "_" (as in, "_lwrp_testing.rb"), but
> feels like
> >> a hack.
> >> 2. Create a recipe fixture for testing the LWRP for use
> >> ChefSpec runs. The recipe would only exist in the
context of a
> >> ChefSpec run, and allow for valid exercise of the
> >> during testing...at the same time, the recipe would not
> >> reals" in the cookbook, and couldn't be assigned to a
> >> seems like an elegant approach (design wise), but my
> >> not to the level they should be to easily implement this.
> Anybody else
> >> try this?
> >> Or, perhaps there's another solution I'm overlooking?
> >> Thanks for your thoughts.
> >> Bryan
> >> PS - Thanks to everybody for another great ChefConf!
> >> --
> >> @millisami
> >> ~Sachin Sagar Rai
> >> Ruby on Rails Developer
> >> http://tfm.com.np
> >> http://nepalonrails.com
> >> References
> >> 1. http://tfm.com.np/
> >> 2. http://nepalonrails.com/
> 1. mailto:firstname.lastname@example.org <mailto:email@example.com>
> 2. mailto:firstname.lastname@example.org <mailto:email@example.com>
> 3. http://tfm.com.np/
> 4. http://nepalonrails.com/
> 5. http://tfm.com.np/
> 6. http://nepalonrails.com/