> 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. >
Then we are talking at cross purposes. I don't think anyone strongly disagrees with your proposal, though I think I lean slightly towards considering it a test failure since the logging of the error is probably a symptom and not a cause, and what we're going to want to track down is the cause. But I would be happy with what you laid out as well. Daniel's objection, I believe, was that the proposed implementation as we were reading it would either be global (and irrevocable) or require pervasive local stubbing (a new before on almost every test) and since we actually want the behavior on most-but-not-all tests, both alternatives seem unworkable. That's why he's focusing on coming up with something that gives a useful default behaviour in the common case but is not particularly onerous to work around in the exceptional cases (e.g., when you want to assert that a failure at some point, which will be logged, won't corrupt something else). -- M ----------------------------------------------------------- When in trouble or in doubt, run in circles, scream and shout. -- 1920's parody of the maritime general prudential rule ------------------------------------------------------------ -- 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.
