[chef] Re: Re: Re: Re: Re: ChefSpec for LWRPs without recipes...


Chronological Thread 
  • From: John Dewey < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: ChefSpec for LWRPs without recipes...
  • Date: Wed, 1 May 2013 09:54:49 -0700


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 
> < >
>  wrote:
> 
>      John is right - it's becoming common to provide an empty default.rb
>      for a cookbook that doesn't have any recipes.
> 
>    On Wed, May 1, 2013 at 12:34 PM, John Dewey 
> < >
>  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!
>    >>
>    >>    --
>    >>    @millisami
>    >>    ~Sachin Sagar Rai
>    >>    Ruby on Rails Developer
>    >>    [1][3]http://tfm.com.np
>    >>    [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.

§