On Tue, Sep 17, 2013 at 12:02 AM, Corey Osman <co...@logicminds.biz> wrote:

> I was able to mock everything by mocking the underlying method calls
> instead of confine itself.
>
>
> example:
>
> Mock existence of files: File.stubs(:exists?).returns(true)
>

You can also create a separate method that wraps the File.exists? call and
returns true...then mock that method's return value.  When you mock out
File#exists?, you have the potential of screwing with every OTHER method
that might be calling File#exists? in your code.


> Mock commands:
> Puppet::Util.stubs(:which).with("ipmitool").returns("/bin/ipmitool")
>

You use a 'let' to instantiate a new instance of your provider like so:

     let(:resource) { Puppet::Type::Bmc.new({<attributes here>}) }
     let(:provider) {
Puppet::Type.type(:bmc).provider(:ipmitool).new(resource) }

You can then mock out the call to the ipmitool binary like so:

    provider.expects(:ipmitool).with('arguments', 'go',
'here').returns('return value')

The returns bit is optional, and you can use .stubs instead of expects to
create a looser test if you need.



> Mock fact:   let(:facts)do {:is_virtual => 'false'} end
>
>
> On Monday, September 16, 2013 4:53:19 AM UTC-7, Andy Parker wrote:
>
>> On Sun, Sep 15, 2013 at 6:50 PM, Corey Osman <co...@logicminds.biz>wrote:
>>
>>> Turns out I had a typo:
>>>
>>> Puppet::Type.type(:bmc).**provide(:ipmitool) do
>>> was
>>> Puppet::Type.type(:bmc).**provider(:ipmitool) do
>>>
>>>
>> Glad that you figured it out! That one letter difference can really bite
>> you and is hard to track down.
>>
>>
>>> Seems to work.
>>>
>>> Now how do I mock things like:
>>>
>>> 1. command :ipmitool
>>>
>>
>> Commands can be mocked by mocking the method on the provider (although it
>> is not great mocking parts of the class that is being tested :(.
>>
>
>
>
>
>
>>
>>
>>> 2. confine :is_virtual => "false"
>>> 3.   confine :true => File.exists?('/dev/ipmi0') ||
>>> File.exists?('/dev/ipmi/0') || File.exists?('/dev/ipmidev/0')
>>>
>>>
>> I'm not sure that you need to worry about mocking the confines since they
>> should only be used when the system is selecting the provider to use during
>> a run, I may be wrong however. Have you found the need to mock them?
>>
>>
>>> Corey
>>> On Sunday, September 15, 2013 6:20:49 PM UTC-7, Corey Osman wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am been trying really hard to test my custom type/provider.  Every
>>>> example seems to not fit my case though.  Most of the examples only cover
>>>> the providers or puppet code.
>>>>
>>>> My case is a type and provider combined.
>>>>
>>>>
>>>> The puppet_labs_spec_helper has at least helped me out. I have been
>>>> following this doc: https://puppetlabs.com/blog/**th**
>>>> e-next-generation-of-puppet-**mo**dule-testing<https://puppetlabs.com/blog/the-next-generation-of-puppet-module-testing>
>>>>  But I still can't get the most basic test to run.  I am assuming this
>>>> is an environment issue as the puppet labs_apache module seems to test just
>>>> fine on my machine and I have tried to borrow and copy the layout as much
>>>> as possible.
>>>>
>>>>
>>>> Could someone explicitly detail the steps required to test my code?
>>>>  Maybe even clone my repo and run: rake spec_prep && rake spec
>>>>
>>>> git clone 
>>>> https://github.com/logicminds/****bmclib<https://github.com/logicminds/bmclib>
>>>>
>>>> Stuck at the following errors:
>>>> error: 
>>>> https://gist.github.**com**/logicminds/6575668<https://gist.github.com/logicminds/6575668>(puppet
>>>>  3.3.0)
>>>> load error: 
>>>> https://gist.github.com/**logicm**inds/6575704<https://gist.github.com/logicminds/6575704>
>>>>  (puppet 3.2.4)
>>>>
>>>> thanks,
>>>>
>>>> Corey
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-dev+...@**googlegroups.com.
>>> To post to this group, send email to puppe...@googlegroups.com.
>>>
>>> Visit this group at 
>>> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev>
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>
>>
>>
>> --
>> Andrew Parker
>> a...@puppetlabs.com
>> Freenode: zaphod42
>> Twitter: @aparker42
>> Software Developer
>>
>> *Join us at PuppetConf 2014, September 23-24 in San Francisco*
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Gary Larizza
Professional Services Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to