stratis-storage/stratis-cli

Increase stratis-cli coverage to 100%

mulkieran opened this issue · 2 comments

mulkieran commented

  • Definition of interface_name_to_common_name is completely uncovered. This is only used in error reporting, to distinguish when a specified thing is not found in the CLI. Related: stratis-storage/project#51. Fixed in #330.

  • Many constructs like:

 if rc != StratisdErrors.OK: 
            raise StratisCliEngineError(rc, message)

are not covered. This reflects the fact that we don't really get many errors back from the engine in this CLI testing, which is understandable. Related: #222. Resolved by #348.

  • The definition of rename_fs is entirely uncovered. We must not be testing the corresponding command-line call. Related: stratis-storage/project#51.

  • The definitions of add_cache_devices and add_data_devices are partially covered in a wierd way. This requires further investigation, since it definitely looks as if the methods are being run, but not as if they are completing normally. Puzzling. Related: stratis-storage/project#51. The only tests that are run test to see that they fail if there is no pool.

  • Most of the definitions of interpret_errors and handle_error are uncovered. That's because some of the errors are hard to engineer. That's mostly because we usually call with --propagate set, because that's more interesting. However, DbusClientUniqueResultError should be fairly easy to engineer. Some of the others might call for monkeypatching. Lots of code in _errors.py, especially the code that generates the error messages is uncovered for the same reason. EDIT: Fixed by #330, #327, #323.

  • The error part of value_to_name's generated function is not covered. This should be easy to engineer a test for. Decided that no coverage would be more sensible, see: #346 .

mulkieran commented

I'm going to see about picking off add_data and add_cache.

mulkieran commented

Closed by attached issues.