On Mar 4, 2011, at 9:25 AM, Markus Roberts wrote:
>> > > This would terminate the operating code inside puppet at that point;
>> > now logging is fatal, and there is no mechanism to suppress that. If
>> > it wasn't for that property I would pretty much entirely agree.
>>
>> Huh; not sure why it's a bad thing to terminate the processing here, since
>> then at least you get a stack trace and such, but I'll take your word for it
>> that it is.
>>
>> Because sometimes we want to write a test that asserts that an error will be
>> logged under certain circumstances, or that some condition is or isn't
>> modified when a condition which results in a logged error occurs. Such
>> tests would always either fail or pass for the wrong reasons.
>
> I thought processing would only stop if the log wasn't stubbed, in which case
> you've got a failure you didn't plan on. If you correctly stub/expect the
> logs, then processing should absolutely continue.
>
> We're far enough into the weeds, and there's grave risk of talking at cross
> purposes, but I'll give what I believe to be the correct answer in context.
>
> The code that started this thread was:
>
> Puppet.stubs(:warning).raises "Failed test"
>
> which Daniel asserted would "terminate the operating code inside puppet" and
> that "there is no mechanism to suppress that." On the face of it, he is
> right about the first and I'd suspect he's right about the second, esp. if
> you modify it to "there's no non-heinous mechanism..." We could, though, be
> wrong, and it may be possible to stub over the stub in some non-heinous way.
>
> The question you asked, though, wasn't why we thought this was true but
> rather why we thought it was bad, specifically you said you were "not sure
> why it's a bad thing to terminate the processing here" and that is what I was
> replying to.
>
> We may be wrong that stubbing the logging mechanism to raise an exception
> would terminate execution "in the middle" but, if that is the case, I believe
> the objection Daniel alluded to is reasonably close to what I expressed.
>
> > Am I missing something?
>
> Given the complexity of || logging + rspec + {all tests present & future} +
> our exception handling + ...? ||, I think it's highly likely that we're all
> missing something. But we struggle on regardless. :)
What I mean is this:
* My understanding is that the goal is to fail when any warning or higher logs
get sent that the tests don't expect
* My experience is that immediate failure with resulting stack trace is always
easier to debug than delayed failure
* Thus, my proposal, which does cause immediate failure with resulting stack
trace, would seem both a simpler and preferred option
What I don't understand is where my logic has gone wrong and why Daniel's
proposal is preferred.
--
When a man tells you that he got rich through hard work, ask
him: 'Whose?' --Don Marquis
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
