PyI40AAS issueshttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues2021-02-25T11:11:48+01:00https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/115These docstrings may need a rework2021-02-25T11:11:48+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deThese docstrings may need a reworkThis is a collection of docstrings that may need some reformulating. I am happy to provide it, though would like to discuss the content beforhand.
* [x] `model.__init__`: Update docstring
* [x] `aas` module docstring and `aas.Asset` sho...This is a collection of docstrings that may need some reformulating. I am happy to provide it, though would like to discuss the content beforhand.
* [x] `model.__init__`: Update docstring
* [x] `aas` module docstring and `aas.Asset` should have a note about how `Assets` are handled now
* [x] `aas.View`: Resolve "Todo: What does this do exactly?" and with resolving, update docstring to be clear about what it does.
* [x] `base.Qualifiable`: Unclear formulation
* [x] `base.HasExtension`: Unclear explanation of attribute `namespace_element_sets`
* [x] `base.Referable.parent`: Confusing by mentioning a `Reference`, even though it is actually a `Namespace`
* [x] `base.Reference.key`: Unclear formulation
* [x] `base.UnexpectedTypeError`: `base.Reference` does not have a method `resolve()`
* [x] `base.ValueReferencePair`: Unclear formulation, does not have any reference to any other part of the meta-model
* [x] `provider.AbstractObjectProvider.get_identifiable`:
* Docstring says "find identifiable by id_short", parameter is of type `base.Identifier` though.
* Missing docstring for ":param: identifier"
* ":raises: KeyError: Mentioning `Referable` here, while correct, may be confusing to some. Maybe use `Identifiable` here?
* [x] `provider.AbstractObjectStore.update`: Missing docstring
* [x] `submodel.OperationVariable`: is in fact, not a `SubmodelElement`
* [x] `submodel.RelationshipElement`: The mentioned subject-object relation is unclear to me. Disregard this, if this a concept I simply don't know
* [x] `Referable.display_name` description is unclear
* [x] `base.Formula`: If we don't support it anymore (in V30RC1, because formulas are not unambiguously identifiable), mention this somewhere where it makes sense
* [x] `aas.adapter.__init__`: Update docstring
* [x] `adapter.json.json_deserialization`: Second paragraph of module docstring seems outdated
* [x] `model.base.LangStringSet`: Has no Entry in the documentation (Due to it being Dict[str, str]) and no class
* [x] `model.base.ValueList`: Has not Entry in the documentation
* [x] `backend.__init__`: Missing module docstring
* [x] `backend.couchdb`: Missing module docstringSebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.dehttps://git.rwth-aachen.de/acplt/pyi40aas/-/issues/88Inability to test for parameter `relative_path` in calls of `backends.Backend...2020-10-28T17:08:35+01:00Sebastian Heppners.heppner@iat.rwth-aachen.deInability to test for parameter `relative_path` in calls of `backends.Backend.update_object()` and `backends.Backend.commit_object()` from `model.base.Referable` using `unittest.mock.Mock`Especially during execution of the `model.base.Referable.commit()` function, the `relative_path` variable is built iteratively by traversing the Referable-tree. Whenever there is a nonempty source, the `backends.Backend.commit_object()` ...Especially during execution of the `model.base.Referable.commit()` function, the `relative_path` variable is built iteratively by traversing the Referable-tree. Whenever there is a nonempty source, the `backends.Backend.commit_object()` function is called with the current `relative_path`. Therefore, the `relative_path` variable is likely to change after a call. This is impractical, because `unittest.mock.call` seems to only log a reference to the variables that were used in that call, rather than saving a duplicate of the current state of those variables during function call.
Here is a minimal example that shows this behavior:
```
from unittest import mock
test_mock = mock.Mock()
test_parameter = ["only_entry_of_this_list"]
test_mock(argument=test_parameter)
test_parameter.append("another_entry_of_this_list")
test_mock.assert_has_calls([mock.call(argument=["only_entry_of_this_list"])])
```
leads to:
```
AssertionError: Calls not found.
Expected: [call(argument=['only_entry_of_this_list'])]
Actual: [call(argument=['only_entry_of_this_list', 'another_entry_of_this_list'])]
```
Therefore, it is impossible to check, if the `relative_path` has been correct during the time of the function call, using the `unittest.mock.Mock`-object.
While I have reviewed with the debugger, that the function gets called with the correct `relative_path` at each time, I don't see a way to "prove it" using unittests, without altering the actual code to allow for testing, which in my opinion shouldn't really be done.Sebastian Heppners.heppner@iat.rwth-aachen.deSebastian Heppners.heppner@iat.rwth-aachen.de