DSP-442 Add Convenience Methods to Ontology Information #265
Conversation
|
@flavens I am already preparing a PR for the advanced search: dasch-swiss/dsp-ui-lib#239 |
|
I will add some more tests on Monday. |
|
Ok, I added the tests. The PR is now ready for review. |
| @@ -143,6 +144,28 @@ describe("OntologiesEndpoint", () => { | |||
| expect((response.properties["http://0.0.0.0:3333/ontology/0001/anything/v2#hasListItem"] as ResourcePropertyDefinition).isLinkValueProperty).toBeFalsy(); | |||
| expect((response.properties["http://0.0.0.0:3333/ontology/0001/anything/v2#hasListItem"] as ResourcePropertyDefinition).guiAttributes).toEqual(["hlist=<http://rdfh.ch/lists/0001/treeList>"]); | |||
|
|
|||
| const classDefs = response.getAllClassDefinitions(); | |||
| expect(classDefs.length).toEqual(9); | |||
There was a problem hiding this comment.
Do you think there is a way to avoid a hardcoded number for all of the length assertions? If the test data changes, this could break so I'm thinking we could maybe make this more flexible.
There was a problem hiding this comment.
That's a good point. However, I think unit tests should have static expectations. The more flexible assertions get, the more complexity grows. I once have written some testing helper method that was quite flexible and I only found out later that it never worked correctly. So the test would not have caught errors correctly.
Nevertheless, I think your point is valid. There is an ongoing discussion about how not to generate (static) test data from Knora anymore, but to manage it inside this lib. This would be possible once there is a formal spec that test data can be validated against. So then we would only care about the formal correctness of the test data, and this wouldn't change unless there is a change in the format spec.
Now, the ontology JSON-LD is actually generated from a test ontology in Knora. If this ontology changes, then the assertions would be wrong and would have to be updated.
kilchenmann
changed the title
resolves DSP-442