Add additional modes to blackbox tests

[mulkieran]

Currently the tests only have one mode, the daemon gets started in setup and stopped in cleanup, and actions and their correctness are verified in between. We probably need more modes:

• A test of setup and device discovery
• A test of D-Bus permission --- we want to verify that unprivileged users have restricted permissions on the D-Bus. This gets even more important with key-handling, I would say.
  • Tests of the D-Bus API
  • Tests of the CLI
• Tests of symlinks, i.e., that they are set and then updated properly on rename of pool or filesystem. It is possible that they could be incorporated into all the existing tests via some general infrastructure. Note that these tests will not be able to be made in a sensible fashion until there is an existing spec file that install the udev rules and the script that produces the correct values for the symlink.

[mulkieran]

I would like the D-Bus permissions test to be address first.

[mulkieran]

We would like to start having some symlinks tests. How?

[jbaublitz]

I feel like this could be as simple as creating a pool and filesystem in the blackbox tests and checking to see if udev created the appropriate symlink. We could even check that the symlink points to the right devicemapper device if that seems like it would be beneficial. Overall, I think we just need to verify that udev created the symlink and when we create a pool and filesystem, we already have those names available so we could simply create them both and see if a symlink exists at the expected path. How does that sound to you?

[mulkieran]

@jbaublitz Yes. That seems reasonable.

[mulkieran]

@bgurney: Could you try writing a symlinks test? The idea here #557 (comment) seems fine to me.

[mulkieran]

Tests of setup and device discovery have the highest risk of failing for reasons outside the control of the tests or stratisd. Therefore, I'll consider this done.