# Testing advice

**URL:** <https://discourse.chef.io/t/testing-advice/6947>\
**Category:** Chef Infra (archive)\
**Created:** [September 30, 2015, 6:48pm UTC](https://discourse.chef.io/t/testing-advice/6947 "2015-09-30T18:48:46Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sean\_Farrow1](https://avatars.discourse-cdn.com/v4/letter/s/7ea924/32.png) [@Sean\_Farrow1](https://discourse.chef.io/u/Sean_Farrow1)\
**Post date:** [September 30, 2015, 6:48pm UTC](https://discourse.chef.io/t/testing-advice/6947/1 "2015-09-30T18:48:46Z")

</div>

Hello,

I am in the process of creating a cookbook that uses other cookbooks/recipe’s.  
What RSpec/ServerSpec tests would people write in this situation?  
Any advice appreciated.  
Kind regards  
Sean.

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [September 30, 2015, 7:20pm UTC](https://discourse.chef.io/t/testing-advice/6947/2 "2015-09-30T19:20:57Z")

</div>

we use chefspec for unit testing, and raw LXC + rsepc (with ruby telnet,  
blender etc based matchers) for integration testing. the whole thing is  
CI/CDed under GoCD. We had blogged about it in past[1]. Its pretty  
backdated now, our spec helper modules have changed a lot after blender  
releases, to support multi node testing (for zk. cass clusters) as well as  
after GoCD became opensource. You can check the GoatOS project which is  
takes similar approach for testing chef along side cookbook against every  
chef master changes.

I have avoided using serverspec for its limitations related to single node  
specs, as well as weird library styles and issue tracking. also during  
functional tests i tend to test the outcome of a chef role/cookbook rather  
than individual resources, like zookeeper functional tests will do a telnet  
against zk hosts' port 2171 and check for stats. Or for mysql its ability  
to upload fixture data.

hth  
ranjib  
[1][Chef Testing at PagerDuty | PagerDuty](https://www.pagerduty.com/blog/chef-testing-pagerduty/)

On Wed, Sep 30, 2015 at 11:48 AM, Sean Farrow [sean.farrow@seanfarrow.co.uk](mailto:sean.farrow@seanfarrow.co.uk)  
wrote:

> Hello,
> 
> I am in the process of creating a cookbook that uses other  
> cookbooks/recipe’s.
> 
> What RSpec/ServerSpec tests would people write in this situation?
> 
> Any advice appreciated.
> 
> Kind regards
> 
> Sean.

---

<div class="post-metadata">

**Author:** ![yoshiwaan](https://avatars.discourse-cdn.com/v4/letter/y/ba9def/32.png) [@yoshiwaan](https://discourse.chef.io/u/yoshiwaan)\
**Post date:** [September 30, 2015, 7:36pm UTC](https://discourse.chef.io/t/testing-advice/6947/3 "2015-09-30T19:36:23Z")

</div>

For the Rspec tests I'm assuming you mean ChefSpec, in which case you only  
cover the code you write in your own cookbook. If you use the berkshelf  
plug-in then it by defaults filters the checks against code only in your  
cookbook. Remember to turn on code coverage resports.

These two posts cover it well:

> **[Unit Testing Chef Cookbooks | Seth Vargo](https://www.sethvargo.com/unit-testing-chef-cookbooks/)**
>
> I spoke at Chef Summit a few months ago and received a lot of questions about ChefSpec. It's very difficult to demonstrate the value in a Unit test when everyone is thinking at a higher level (acceptance testing).

> **[Chef recipe code coverage | Seth Vargo](https://www.sethvargo.com/chef-recipe-code-coverage/)**
>
> The wait is over! Chef recipe code coverage is now in ChefSpec! Easily find which resources have not been touched and generate a comprehensive coverage report at the end of each run.

For the ServerSpec tests you check that the end result scenario of all of  
your cookbook code worked, e.g. so certain services are started, certain  
files are created as the end result of a run (not files deployed by chef),  
certain ports are listening and so on. Avoid duplicating tests that the  
upstream cookbooks already implement and there's little point duplicating  
tests implemented by ChefSpec unless you're super duper paranoid about  
something working.

On 30 September 2015 at 11:48, Sean Farrow [sean.farrow@seanfarrow.co.uk](mailto:sean.farrow@seanfarrow.co.uk)  
wrote:

> Hello,
> 
> I am in the process of creating a cookbook that uses other  
> cookbooks/recipe’s.
> 
> What RSpec/ServerSpec tests would people write in this situation?
> 
> Any advice appreciated.
> 
> Kind regards
> 
> Sean.

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [September 30, 2015, 8:11pm UTC](https://discourse.chef.io/t/testing-advice/6947/4 "2015-09-30T20:11:25Z")

</div>

By the way: has anybody from this list actually tried infrataster or  
leibniz for multi-node integration testing?

That's one of the things on my list I always wanted to check out but really  
never came to it yet...

​[0]​ [http://infrataster.net/](http://infrataster.net/)  
​[1] [https://github.com/Atalanta/leibniz​](https://github.com/Atalanta/leibniz%E2%80%8B)

On Wed, Sep 30, 2015 at 9:36 PM, Yoshi Spendiff [yoshi@spendiff.net](mailto:yoshi@spendiff.net) wrote:

> For the Rspec tests I'm assuming you mean ChefSpec, in which case you only  
> cover the code you write in your own cookbook. If you use the berkshelf  
> plug-in then it by defaults filters the checks against code only in your  
> cookbook. Remember to turn on code coverage resports.
> 
> These two posts cover it well:  
> [Unit Testing Chef Cookbooks | Seth Vargo](https://sethvargo.com/unit-testing-chef-cookbooks/)  
> [Chef recipe code coverage | Seth Vargo](https://sethvargo.com/chef-recipe-code-coverage/)
> 
> For the ServerSpec tests you check that the end result scenario of all of  
> your cookbook code worked, e.g. so certain services are started, certain  
> files are created as the end result of a run (not files deployed by chef),  
> certain ports are listening and so on. Avoid duplicating tests that the  
> upstream cookbooks already implement and there's little point duplicating  
> tests implemented by ChefSpec unless you're super duper paranoid about  
> something working.
> 
> On 30 September 2015 at 11:48, Sean Farrow [sean.farrow@seanfarrow.co.uk](mailto:sean.farrow@seanfarrow.co.uk)  
> wrote:
> 
> > Hello,
> > 
> > I am in the process of creating a cookbook that uses other  
> > cookbooks/recipe’s.
> > 
> > What RSpec/ServerSpec tests would people write in this situation?
> > 
> > Any advice appreciated.
> > 
> > Kind regards
> > 
> > Sean.

---

<div class="post-metadata">

**Author:** ![yoshiwaan](https://avatars.discourse-cdn.com/v4/letter/y/ba9def/32.png) [@yoshiwaan](https://discourse.chef.io/u/yoshiwaan)\
**Post date:** [November 30, 2015, 10:10pm UTC](https://discourse.chef.io/t/testing-advice/6947/5 "2015-11-30T22:10:17Z")

</div>

Sorry about the super slow response. I think I got unsubscribed to a list or two.

I would check if the upstream cookbook already has tests and make sure not to duplicate them (which will save you a lot of work).

You would want to at least test for your include\_recipe statements if you are including recipes, otherwise if you are using cookbooks that only expose resources you can just test your declared resources like standard Chef resources in ServerSpec (so long as that cookbook includes a matchers.rb library)