sensu-plugins / community

Your place to contribute to Sensu plugins and their maintainers
http://sensu-plugins.io
MIT License
21 stars 12 forks source link

Add integration testing for all the plugins repos #41

Open majormoses opened 7 years ago

majormoses commented 7 years ago

See example PRs linked below!

luisdavim commented 7 years ago

I believe sensu-plugins-dcos is covered.

barryorourke commented 6 years ago

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

absolutejam commented 6 years ago

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

majormoses commented 6 years ago

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.

absolutejam commented 6 years ago

@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.

majormoses commented 6 years ago

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:

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:

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.