>
> 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 [email protected]
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.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]