Well for example if i use your puppet-module-skeleton... create a module 
that uses the rspec-puppet-facts for centos 5,6,7.
include ::selinux (jfryman/selinux)
in coverage report it shows the following missing:

 Package[policycoreutils-devel]

 Package[policycoreutils-python]

 Package[policycoreutils]


first is for 7, second for 6, and third for 5 major releases.

While I can test for these in my _spec test I'd rather only be testing that 
class_selinux is included and any parameters I might be using against it. 
or maybe even the selinux::module or selinux::boolean resources that I 
might be setting... 


should hopefully be a pretty simple test to reproduce but it's definitely 
not excluding those resources if that's what that merge was intended for.



On Friday, June 17, 2016 at 11:37:40 AM UTC-4, garethr wrote:
>
> On 17 June 2016 at 15:24, Chris Denneen <[email protected] <javascript:>> 
> wrote: 
> > Gareth, 
> > 
> > I know this thread is old but do you have a way in the Rakefile to 
> exclude 
> > the dependent modules? 
> > For example dependent modules that include different package resources 
> based 
> > on OSfamily and version are something that module controls and tests I 
> just 
> > need to make sure that the module is included in my catalog and any 
> defined 
> > types used in my module get tested. (dependentmodule::resource['foo']) 
> > I've seen some other posts hacking rspec coverage.rb which probably 
> isn't 
> > good (https://github.com/rodjek/rspec-puppet/issues/364). 
> > I've noticed the filtered?(resource) in rspec-puppet just documented of 
> how 
> > to implement. 
> > Hopefully you can help here. 
> > 
>
> I _think_ the coverage support now does this by default? 
>
> Anything from fixtures should now be ignored. 
> https://github.com/rodjek/rspec-puppet/pull/258 
>
> Other folks have made a whole bunch of improvements to the coverage 
> support in rspec-puppet since I added it. 
>
> Gareth 
>
> > Thanks 
> > 
> > On Friday, February 7, 2014 at 5:54:06 AM UTC-5, garethr wrote: 
> >> 
> >> On 7 February 2014 02:51, gh <[email protected]> wrote: 
> >> > On 1/26/14 7:50 AM, Gareth Rushgrove wrote: 
> >> >> For anyone else who likes writing tests for their puppet manifests, 
> >> >> I've just added basic code coverage to rspec-puppet: 
> >> >> 
> >> >> A blog post here about how to use it: 
> >> >> 
> >> >> 
> >> >> 
> http://www.morethanseven.net/2014/01/25/code-coverage-for-puppet-modules/ 
> >> >> 
> >> >> I'd be interested in any feedback on how to improve or add to this. 
> >> >> 
> >> >> Cheers 
> >> >> 
> >> >> Gareth 
> >> >> 
> >> > 
> >> > Gareth, 
> >> > 
> >> > Great blog post. I tried this on a module with 100% coverage and 
> notice 
> >> > that it reports back 50% coverage. After some poking around, found 
> that 
> >> > it is checking code in spec/fixtures/, the stdlib module actually. 
> There 
> >> > seems to be an open issue[1] regarding the inability to exclude 
> things. 
> >> > Curious if you found a work around for testing your code and not the 
> >> > modules pulled in from .fixtures.yml. 
> >> > 
> >> 
> >> Currently the rspec-puppet coverage stuff does check coverage across 
> >> all resources, including those from dependent modules. For example 
> >> this module depends on the puppetlabs/apt module - 
> >> https://travis-ci.org/garethr/garethr-nginx/jobs/18133670#L113 
> >> 
> >> I purposefully didn't add too much configuration to the first pass of 
> >> the code, but it would be simple to add some options to ignore 
> >> specific modules (I think). I thought I'd wait to see if anyone found 
> >> it useful first. 
> >> 
> >> Gareth 
> >> 
> >> > [1] - https://github.com/lemurheavy/coveralls-public/issues/184 
> >> > 
> >> > BR, 
> >> > -g 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Puppet Users" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >> > an email to [email protected]. 
> >> > To view this discussion on the web visit 
> >> > 
> https://groups.google.com/d/msgid/puppet-users/52F44A2E.3070903%40garretthoneycutt.com.
>  
>
> >> > For more options, visit https://groups.google.com/groups/opt_out. 
> >> 
> >> 
> >> 
> >> -- 
> >> Gareth Rushgrove 
> >> @garethr 
> >> 
> >> devopsweekly.com 
> >> morethanseven.net 
> >> garethrushgrove.com 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to [email protected] <javascript:>. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/2d63d692-f837-42da-a44e-c5b73dbfa015%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Gareth Rushgrove 
> @garethr 
>
> devopsweekly.com 
> morethanseven.net 
> garethrushgrove.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/459f2f42-a5d0-4c6b-80a3-acb9de3abd61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to