[chef] Re: Re: Re: Re: Re: Continuous Integration


Chronological Thread 
  • From: AJ Christensen < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Continuous Integration
  • Date: Thu, 8 Jul 2010 16:14:05 +1200

It seems what we're all really talking about is some kind of BDD framework for Chef cookbooks - unit testing (also related to --noop) has proven unreliable for this kind of thing: you can't mock UNIX.

I know there was work done on this in the past - mikehale's chef-bdd project http://github.com/mikehale/chef-bdd for example.

On 8 July 2010 15:55, Chad Woolley < "> > wrote:
On Wed, Jul 7, 2010 at 8:09 PM, Erik Kastner < "> > wrote:
>
>
> I wonder if something like this could be useful (at least for file, dir, template, etc)
> http://github.com/defunkt/fakefs

Ah, you are thinking unit testing, where I was thinking integration testing.

In my experience, unit testing Ops/OS/Deploy code is an exercise in
futility.  You can faithfully test drive the implementation as you
THINK it should be, but you invariably find that it doesn't work as
you expected, because of some unexpected behavior/interaction of the
OS or system.  So, you change the code to actually work on the real
system, then change your tests to match the code.  That is pretty
pointless, it doesn't even buy you the regression safety net of normal
unit tests (because upgrades to the OS/System could break you at any
time, even if your chef code doesn't change).  I suppose it does
provide syntax checking, but that's not worth the considerable effort,
in my opinion.

On the other hand, saying "after I run Chef, assert that a real remote
system should have the package X installed and service Y running" is
pretty useful.

-- Chad




Archive powered by MHonArc 2.6.16.

§