On Aug 9, 2009, at 1:49 PM, Brice Figureau wrote:
>
> On 9/08/09 20:27, Luke Kanies wrote:
>> On Aug 8, 2009, at 5:12 AM, Brice Figureau wrote:
>>
>>> On 8/08/09 0:43, Luke Kanies wrote:
>>>> The patch looks good, but I'd like to see an integration test that
>>>> covers the problem that occurred in this case -- you've got
>>>> exported
>>>> and virtual resources from the client and exported but not virtual
>>>> resources from other hosts. That should catch any issues we might
>>>> have here in the future.
>>> Sure, but I really don't see how I could do that in a simple way. Do
>>> you
>>> have any ideas I could start with?
>>
>> Something like:
>>
>> def resource(desc, exported, virtual)
>> @dir ||= tempfile("exported_virtual_test")
>> Dir.mkdir(@dir) unless FileTest.directory?(@dir)
>>
>> res = Puppet::Parser::Resource.new(:type => :file, :title =>
>> tmpfile(desc), :params => {:ensure => :present})
>> res.exported = exported
>> res.virtual = virtual
>> @catalog.add_resource res
>> end
>>
>> it "should ignore virtual resources but not exported resources" do
>> @catalog = Puppet::Resource::Catalog.new("myhost")
>> resource("exported_and_virtual", true, true)
>> resource("exported_not_virtual", true, false)
>> resource("virtual_not_exported", false, true)
>> resource("neither", false, false)
>>
>> ral = @catalog.to_ral
>> ral.apply
>>
>> # make sure the files that should exist do
>> end
>>
>> No idea if this will quite work or if it exercises all of the code in
>> question, but I think it's the basic idea.
>
> It exercises only the last part of the code (ie transaction). It
> doesn't
> cover the compilation, collection and catalog filtering (note: catalog
> filtering is already covered by an integration test), but that might
> be
> enough.
Ok, was afraid of that.
>
>> You could also just create
>> a manifest that does most of it, add in a collection, and stub that
>> collection to add in these resources that could act like they were
>> collected from other hosts.
>
> This will be really an end-to-end test.
> I'll see what I can do.
>
> Right now integration tests are each in their own file corresponding
> to
> the source code file they covers. But in some cases like the one you
> present above, those integration tests covers large parts of the code
> (here the catalog, the transaction and the ral). So question is, in
> which test file would you put such test?
I consider the integration tests to be not that well thought out, in
general, so I'm quite open to other ways of organizing them, and it's
definitely clear that organizing integration tests by individual
classes doesn't make sense.
Just keep in mind that it'd be nice if autotest maps were written for
whatever method is used, so we get automatic tests run.
--
Reality is that which, when you stop believing in it, doesn't go
away. -- Philip K. Dick, "How to Build a Universe"
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
