Write a python wrapper for Shell files unit testing

[iranzo]

Write a wrapper plugin in tests/ that can search for .sh tests with patterns:

test_$COMPONENT_fail.sh
test_$COMPONENT_pass.sh
test_$COMPONENT_skip.sh

that take care of creating fake files in a fake folder that is passed to citellus for checking that results are expected ones

[iranzo]

@larsks what do you think about something like this to get some kind of unit testing for shell scripts?

[larsks]

I think some sort of testing for the plugins would be a good idea. I'm not sure about this particular scheme, though, because $COMPONENT would be hard to specify (that is, if you want to test plugins/pacemaker/stonith_enabled.sh, what is $COMPONENT?).

An alternative would be to have the test look for a directory named after the plugin, and use that as the filesystem snapshot for testing the plugin. For example, for testing plugins/pacemaker/stonith_enabled.sh, we would look for a directory tests/snapshots/pacemaker/stonith_enabled.sh_pass, and then run:

docitellus(live=False, path=`tests/snapshots/pacemaker/stonith_enabled.sh_pass`, plugins=[the_plugin])

And then assert that the plugin result is successful.

How does that sound? I am making this up as I go along, but it seems to offer a fair amount of flexibility.

[iranzo]

My idea was to write 'test_pacemaker_fail.sh so it precreates required files so the .sh file fails (actual test)

and use 'pacemaker' as filter for the plugins to use

The second approach is also good, but puts more 'data' in the git repo while the other, creates it on the fly

[larsks]

Well, you have the same data in both cases. In my case it lives on disk in files where it can be used as is, while in your example it lives in the scripts and is written out for each test run. I guess implement a couple of tests and see how things work out.

[iranzo]

@larsks https://review.gerrithub.io/374645 check that one

[iranzo]

Merged as separated tests per plugin