On Mar 4, 2011, at 2:19 PM, Paul Berry wrote:
> On Fri, Mar 4, 2011 at 8:39 AM, Luke Kanies wrote:
> On Mar 4, 2011, at 8: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 t
On Fri, Mar 4, 2011 at 8:39 AM, Luke Kanies wrote:
> On Mar 4, 2011, at 8: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 wou
> 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
> What I don't understand is where my logic has gone wrong and why Daniel's
> proposal is preferred.
>
The logic is fine, but:
1) We've got some learned skittishness on relying on mocha for this
sort of thing
2) If your problem is that you're over-catching exceptions, raising an
exception when you
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'
>
> > > 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,
On Mar 4, 2011, at 8: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 b
> > 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
> th
On Mar 3, 2011, at 11:14 PM, Daniel Pittman wrote:
> On Thu, Mar 3, 2011 at 21:40, Luke Kanies wrote:
>> On Mar 2, 2011, at 5:07 PM, Daniel Pittman wrote:
>>> On Wed, Mar 2, 2011 at 16:32, Ben Hughes wrote:
On Wed, Mar 02, 2011 at 03:24:32PM -0800, Daniel Pittman wrote:
> After ev
On Thu, Mar 3, 2011 at 21:40, Luke Kanies wrote:
> On Mar 2, 2011, at 5:07 PM, Daniel Pittman wrote:
>> On Wed, Mar 2, 2011 at 16:32, Ben Hughes wrote:
>>> On Wed, Mar 02, 2011 at 03:24:32PM -0800, Daniel Pittman wrote:
>>>
After every single test in the spec suite, assert that there are no
On Mar 2, 2011, at 5:07 PM, Daniel Pittman wrote:
> On Wed, Mar 2, 2011 at 16:32, Ben Hughes wrote:
>> On Wed, Mar 02, 2011 at 03:24:32PM -0800, Daniel Pittman wrote:
>>
>>> After every single test in the spec suite, assert that there are no
>>> log messages at error or higher in the collected l
On Wed, Mar 2, 2011 at 16:32, Ben Hughes wrote:
> On Wed, Mar 02, 2011 at 03:24:32PM -0800, Daniel Pittman wrote:
>
>> After every single test in the spec suite, assert that there are no
>> log messages at error or higher in the collected logs, before we flush
>> them. If there are, fail hard, an
On Wed, Mar 02, 2011 at 03:24:32PM -0800, Daniel Pittman wrote:
> After every single test in the spec suite, assert that there are no
> log messages at error or higher in the collected logs, before we flush
> them. If there are, fail hard, and treat it as disaster.
This looks a really good addit
I think this is a great idea. It'll catch a ton of problems that we
otherwise miss, as you say, and I've been bitten a lot by them. I
think it'll also encourage us to have better log and error hygiene in
general.
It will almost definitely result in a ton of failing tests at first,
so expect to s
So, we have a history of problems turning up where we write tests that
look like they are passing, then it later turns out that we actually
caught the exception, emitted a nasty error to the logs, and
everything *looked* right from the perspective of the test code.
Which is nasty, especially when t
15 matches
Mail list logo
