Refactor/381 test ld container#398
Conversation
| cont_parent = ld_container({"ham": [{"@value": "eggs"}]}) | ||
| cont = ld_container({"spam": [{"@value": "bacon"}]}, parent=cont_parent) |
There was a problem hiding this comment.
Construction principle for parent/child containers should be the following (even though, you should not construct ld_container instances due to their abstractness and internal nature ;) )
child_data = [{"spam": [{"@value": "bacon"}]}]
parent_data = [{"ham": child_data}]
cont_parent = ld_container(parent_data)
cont = ld_container(child_data, parent=cont_parent, key="ham")Important information that is hidden here (and should be explicited in documentation aritfacts):
ld_containerclasses work as proxies and reflect the content and structure of the maintained datasets.- All parent-child-relations of
ld_containersneed to be existent in the base dataset for this to work. (The opposite is not required). - All datasets that are maintained by the
ld_containerare handled by reference! I.e., if you change something in the ld_container, it will be changed in the dataset directly. There is no place where a container creates a copy of the base dataset. - If a container has a
parent, it is expected to have eitherindexorkey(but not both).
There was a problem hiding this comment.
That helps a lot, thank you!
SKernchen
changed the title
|
|
||
| def test_to_expanded(self): | ||
| cont = ld_container([{"spam": [{"@value": "bacon", "@id": "ham", "@type": "@id"}]}]) | ||
| cont.active_ctx['_uuid'] = str(uuid.uuid1()) # FIXME: 406 |
There was a problem hiding this comment.
Okay, active_ctx is something internal to pyld and is used here ... as some kind of shortcut. Problem is, that is even for pyld something internal and hence not (very well) documented.
I still see that #406 is an issue, though. Again, a stacktrace would be helpful (but I can also run the tests myself for further analysis).
The other question is, how _to_expanded_json should behave on undefined properties...
See MR #398 for more information.
| def test_to_python(self): | ||
| cont = ld_container([{"spam": [{"@value": "bacon", "@id": "ham", "@type": ["@id"]}]}]) | ||
| assert cont._to_python("spam", [{"@value": "bacon"}]) == 'bacon' | ||
| assert cont._to_python("@id", "ham") == "ham" | ||
|
|
||
| cont.active_ctx['_uuid'] = str(uuid.uuid1()) # FIXME: 406 | ||
| assert cont._to_python("@type", ["@id"]) == '@id' | ||
|
|
||
| def test_to_expanded(self): | ||
| # Define a mock vocabulary to work with | ||
| mock_context = { | ||
| "ham": {"@id": "http://ham.eggs/ham", "@type": "@id"}, | ||
| "spam": {"@id": "http://ham.eggs/spam"}, | ||
| "Eggs": {"@id": "http://ham.eggs/Eggs"}, | ||
| } | ||
|
|
||
| # Create container with mock context | ||
| cont = ld_container([{}], context=[mock_context]) | ||
|
|
||
| # Try simple cases of expansion | ||
| assert cont._to_expanded_json("spam", "bacon") == [{"@value": "bacon"}] | ||
| assert cont._to_expanded_json("@id", "ham") == "http://ham.eggs/ham" | ||
| assert cont._to_expanded_json("@type", "@id") == ["@id"] |
There was a problem hiding this comment.
Okay, testing these two methods will be tough. They basically reflect the 'inner magic' of the type mapping.
This means we should carefully select suitable test cases. Also it is important that the context is valid and reflects the vocabulary used in the test case.
Basically, this is a small but somewhat representative vocabulary that can be used. In addition, there are two representations of the same document (compact, expanded).
cont.active_ctx is very special with regards to the implementation of a dependency. This is ugly and tests will be added to test_pyld_utils.
The conversion tests (`_to_python` and `_to_expanded_json`) are pretty long now...
|
Finally, the expected test failures show up. These need in fact to be fixed (see #412). Fixing this in refactor/data-model and merging it back to profit from other updates, too. |
…or/381-test-ld_container # Conflicts: # poetry.lock
Update poetry.lock for added test dependencies.
2 participants
Test ld_container