search

naemon / naemon-core

Networks, Applications and Event Monitor
http://www.naemon.io/
GNU General Public License v2.0
154 stars 63 forks source link

t-tap tests are not run on 'make check' #12

Closed catharsis closed 10 years ago

catharsis commented 10 years ago

There are a bunch of tests in the t-tap directory that are no longer run. That is unfortunate since at least some of them are useful.

Is this intentional? If so, what are the plans on porting those tests to whatever framework we're supposed to use instead?

ozamosi commented 10 years ago

The autotools code for running them was deleted and not reimplemented as part of the great doing-autotools-less-insanely shuffle. So no, I don't think it's intentional.

ageric commented 10 years ago

On 2013-12-20 11:58, Anton Löfgren wrote:

There are a bunch of tests in the t-tap directory that are no longer run. That is unfortunate since at least some of them are useful.

Is this intentional? If so, what are the plans on porting those tests to whatever framework we're supposed to use instead?

It was sort of intentional, since only two (or three?) of the tests actually work at all. I was fiddling with trying to get it to work, but only for a few minutes, before I gave up on them.

Patches welcome, obviously, but I'd sooner get rid of libtap than expand on its use.

/Andreas

ozamosi commented 10 years ago

Now the tests that used to work in nagios are run on make check again in naemon. And we've got the check framework for writing new tests. So, basically: jay, I get to close.

catharsis commented 10 years ago

Brilliant. I'm thinking it might make sense to add a note of preferred test frameworks in the developer guidelines (or whatever they're called) in order to avoid attracting new test cases to "deprecated" suites.

ozamosi commented 10 years ago

Oh, we have developer guidelines? :D Are you referring to the readme?

But, yeah, we need a clear overview of what we expect from submitted patches, or submitted patches won't fulfil those expectations.

catharsis commented 10 years ago

My thoughts exactly.

dwittenberg2008 commented 10 years ago

How about a wiki for that kind of stuff, let everyone provides notes on development? Be nice to have some new docs on QH/livestatus and even solid NEB docs, I’m willing to help with those too, don’t mind doing documentation.

Dan

On Feb 3, 2014, at 7:36 AM, Robin Sonefors notifications@github.com wrote:

Oh, we have developer guidelines? :D Are you referring to the readme?

But, yeah, we need a clear overview of what we expect from submitted patches, or submitted patches won't fulfil those expectations.

— Reply to this email directly or view it on GitHub.

sni commented 10 years ago

although i like the idea of a wiki, the current pages allow you already to submit pull requests. So anyone willing to contribute, can do that already. I'd like to have not too many places for documentation. So i'd like to put everything on the website. We even should think about moving the API docs on the website. It shouldn't be a big problem, as long as we mark new things with a version number, like "(new in 1.5)". A wiki would make editing pages even easier, but i think its hard to integrate into Jekyll and its not that hard to change the content right now.