Errors while testing Nagios

[Andreas Ericsson]

On 10/25/2010 11:00 AM, Ton Voon wrote:
> 
> On 23 Oct 2010, at 15:08, Andreas Ericsson wrote:
> 
>> On 10/23/2010 04:04 PM, Andreas Ericsson wrote:
>>> On 10/23/2010 11:33 AM, Andreas Ericsson wrote:
>>>> On 10/23/2010 12:21 AM, Mathieu Gagné wrote:
>>>>>
>>>>> Tests are both resulting in the same errors and failures.
>>>>>
>>>>> Am I missing libraries or did I miss steps?
>>>>>
>>>>
>>>> I've moved code around and not catered to Ton's tests when I went
>>>> on my
>>>> reorganization spree, so it's likely that particular tree is
>>>> broken wrt
>>>> testing.
>>>>
>>>> I'll see if I can get around to fixing it today.
>>>>
>>>
>>> Well, lo and behold. Tests run just fine for me now, and I managed to
>>> push the outstanding patches to the public CVS stuff. I even found a
>>> bug I'd introduced thanks to Ton's awesome tests :)
>>>
>>
>> Bleh. I spoke too soon. Fix coming up in a couple of minutes.
> 
> Fantastic! I can see tinderbox is back to green: http://tinderbox.nagios.org/nagios/status.html
> 

Awesome :)

Though I must say I really detest the tap() style of testing. I guess
there's no help for it though, and you're the designated testing master
so I won't object too strenuously ;)

> Re: test_checks, which I notice you've changed from including the main
> source. I had an idea to try a different technique (include the
> source, but override some specific functions), but I couldn't redefine
> functions in C without the compiler complaining. The aim was to try
> and isolate specific functions by mocking other function calls to do
> more scenario-based/complicated testing. I'd welcome any ideas on how
> to do this better.
> 

There's no sane way to do that. The un-sane way is to sed out the functions
you want to replace and then source the sed'ed source-file. A much better
solution is to break the various files down into small and easily-testable
API's. Preferrably object-oriented such, so you call each function as
check.run(), notify.send() and so on. Then you replace the functions by
the simple expedient of just replacing a variable in the API object struct.

Using such an object-oriented way to API's would also make it possible for
eventbroker modules to hijack core functionality, which would definitely
be a worthwhile change, as it'd make it a lot easier to try out new ideas
in the shape of eventbroker modules (although they wouldn't be eventbroker
modules anymore; Just regular demandloadable code).

The downside is that people may well think we're either crazy or brilliant
to use object-oriented programming in a language that wasn't designed for
it, and we'll have to maintain the old way of calling functions unless we
want to break both ABI and API for current modules.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev