You test it like anything else. A trivial example:
https://github.com/retr0h/cookbook-parted/blob/master/spec/_test_spec.rb
John
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 ChefRunner to
> 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 cookbook into
> 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, and leave
> them out of the actual recipe folder (so they're unable to be used in a
> run_list).
> If/when I get something worthy of sharing, I will.
> Bryan
>
> On Wed, May 1, 2013 at 9:38 AM, Mike <[1] "> > wrote:
>
> John is right - it's becoming common to provide an empty default.rb
> for a cookbook that doesn't have any recipes.
>
> >> [1][3]http://tfm.com.np> On Wed, May 1, 2013 at 12:34 PM, John Dewey <[2] "> > wrote:
> >
> > 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 "Berkshelf Way",
> I'm
> >> trying to create a library cookbook which contains some custom
> LWRPs.
> >> This library cookbook will not have any meaningful recipe on its
> >> own...it will only supply providers and resources to be consumed
> by
> >> application cookbooks.
> >> I'd like to test the library cookbook separately, and I think
> ChefSpec
> >> is the correct approach for unit testing. I see that ChefSpec
> takes a
> >> recipe list when "converging", but, since my library cookbook
> won't
> >> have recipes, I don't have one to give to ChefRunner.
> >> I suppose I'd like some suggestions/experiences on how to do
> this.
> >> From my perspective, I can see at least two ways to solve it
> (with a
> >> STRONG preference on the latter):
> >> 1. Create a "lwrp_testing.rb" recipe which will specifically call
> out
> >> to each LWRP the library cookbook provides. I don't like this
> cause
> >> then I've got a testing recipe floating around which COULD be
> applied
> >> to a node in production - and that's just silly. I could prefix
> this
> >> recipe with a "_" (as in, "_lwrp_testing.rb"), but again, it
> feels like
> >> a hack.
> >> 2. Create a recipe fixture for testing the LWRP for use only
> during
> >> ChefSpec runs. The recipe would only exist in the context of a
> >> ChefSpec run, and allow for valid exercise of the underlying
> LWRPs
> >> during testing...at the same time, the recipe would not exist
> "for
> >> reals" in the cookbook, and couldn't be assigned to a run_list.
> This
> >> seems like an elegant approach (design wise), but my Ruby skills
> are
> >> 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!
> >>
> >> --
> >>
> >> ~Sachin Sagar Rai
> >> Ruby on Rails Developer
> >> [2][4]http://nepalonrails.com
> >>
> >> References
> >>
> >> 1. [5]http://tfm.com.np/
> >> 2. [6]http://nepalonrails.com/
>
> References
>
> 1. mailto: ">
> 2. mailto: ">
> 3. http://tfm.com.np/
> 4. http://nepalonrails.com/
> 5. http://tfm.com.np/
> 6. http://nepalonrails.com/
Archive powered by MHonArc 2.6.16.