Add integration testing for all the plugins repos about community HOT 6 OPEN

I believe sensu-plugins-dcos is covered.

from community.

sensu-plugins-load-checks can be ticked of now.

from community.

This is actually a subset as it has probably not been updated for any new plugins added since it's creation but yes there are 180+ plugins. It is a very large effort to push this kind of testing across all the plugins. I will have some blog posts coming out talking about this.

from community.

I need to create something a bit more formal in the form of a best practices doc but between the following links I think is a good start while I work on writing this up better:

• https://blog.sensuapp.org/our-approach-to-testing-sensu-plugins-869260eba94c
• https://blog.sensuapp.org/writing-sensu-plugin-tests-with-test-kitchen-and-serverspec-b646d2eeee51

Also I have added the example you mentioned to the skel along with the skeleton of all the framework config. I think this is a very good start for now.

As far as things to test I think that really depends on the particular plugin so we might want to make individual issues for more specific things But I think there are a few universal things to check:

• is each check executable and has a working ruby environment? See a shared example and it's invocation
• do passing conflicting args/config through an unknown|3?
• Each check/metric, handler, mutator should probably have a min of 1 positive (returns ok|0) check and another to demonstrate that say a critical|2 or |warning|1 threshold is met. Certainly no hard rule and ideally there will be more checks for more things but I find that just doing something makes it easier for people to grok what you want when you ask them to add tests if there are already tests in the repos.

If I had to start in a new repo I find the easiest ones to work with are the high level checks like ping, alive, healthy, etc. It usually requires the least amount of effort to bootstrap/mock and test. This sets the stage without figuring out how to do multi master postgres replication. While eventually we will want this eventually start with the simplest of use cases. The more complicated stuff will come when people start seeing the value of the tests failing when they break stuff.

I have linked a few examples in this issue as well. I'd like an actual doc in addition to the blog posts, skel enhancements, and the few I have done so far is what I have time for right now. Maybe next week I will start creating this more formal document with more examples and talking about what types of things to test but there is some of that in the blog posts already.

One more thing to add is to start looking at your actual check definitions and try to write a test for each one with those options (not necessarily the values but exercising the options). If even 10% of people using plugins did this we would have crazy good coverage. Ideally we would cover every option but I suggest testing either what you are doing (being selfish is ok on this matter) or to distill the most common use cases. Ones that are super generic like check-http.rb might be a little hard to start thinking about as there are so many things to check but I am available to shed some light on a per case basis until we have done enough analysis across all the plugins to come up with a better list of things to check. The best tests are basically just using them like you would in production. If you have to tell your test to do funky things then it is probably not the best test as you are already changing what you are doing from production. One of the reasons I wrote those tests like that is because that how you would actually test it manually. You would create some DNS records and then check for the ones you want the same as cli or through a sensu check definition.

from community.

This list amazes me. Didn't realise there were so many.

from community.

@majormoses is there a good place to provide some example tests or things to test?

I know one example that would have helped me when I was trying to get to grips with both Ruby and rspec for a PR I submitted is check-dns-shared. The tests for CLI args are really clear and concise (And I'm determined rewrite mine to match, haha), but they act as a great sanity check that anyone can write.

from community.