stratis-storage / stratisd-client-dbus Goto Github PK

We have some very good reasons to do so: stratis-storage/stratis-cli#34

It would be nice to make it cleaner.

It generates a ManagedObjects class that it is not really well worked out. It is probably better to write out this class explicitly.

this could be useful, because tests that test just the D-Bus API could always just be run agains the sim engine.

Right now, all tests that require starting up the stratisd service are in the subdirectory dbus.

If our code is correct wrt. to stratisd API then all such errors will be caused by a a missing object path. Under that assumption, what should we do?

Pytest is hiding almost everything about the exception that is raised.

This can wait until the stratisd D-Bus implementation is a bit steadier.

The first step may just be to check that the introspection information is as expected on the properties.

The second is to check that a change actually causes the correct information to be emitted.

Almost all of the classes are dynamically generated from data in tables and almost all the data in these tables could be obtained from introspection data.

The only two exceptions are the input converters, which turn None or a value into an option tuple to put on the Dbus and the class which dynamically generates constants information. That class needs to read the GetManagedObjects result , not the introspect data.

Would the library without those two things be useful? Yes, absolutely.

Would like such tests to use property to get good redundancy values.

This is a low priority because there is not a lot of code and it works.

Could this be helpful...much else would be required.

Right now, all that is verified is signature.