Challenge: Current Testing Strategy Inadequate for Relationships
To make it easy to assert equality between expected and actual test data, we need to create the exact test data in the fixture that we expect to be returned in during the test. But links can't be created in fixtures. How should we handle this?
Resolution: Leverage 'Keys'
In data fixtures, instead of attempting to build test data directly, focus on creating test entry builders and test relationship builders. These builders use primary keys instead of ActionHashes as identifiers.
In the Descriptors repo, type_names are primary keys, so the more sophisticated approach based on uniqueness constraints can be deferred to MAP Holons repo.
Design Summary
Relationships will be represented by links (not SmartLinks)
Fixtures create Test Cases consisting of builders (for HolonDescriptors, ValueDescriptors, PropertyDescriptors, DanceDescriptors, RelationshipDescriptors and Schemas)
Data creators build entries from builders
Test functions maintain IdMap tables that map key strings (i.e., type_names) to ActionHashes. Probably, HolonDescriptors, ValueDescriptors, RelationshipDescriptors and DanceDescriptors can share an IdMap. Schemas could share the same map, but use name as key instead of type_name. PropertyDescriptors are basically owned by HolonDescriptors, so each HolonDescriptor can have its own PropertyDescriptor IdMap.
Test Function Logic
The test functions, implement the following phases:
Make a pass through the test entry builders supplied by the test case, using data_creators to create EntryTypes. When an entry is created, add an entry in a IdMap table, that maps the entry's primary key value to its newly minted ActionHash identifier.
Make a pass through the newly created Entries and lookup ActionHash identifiers for any direct (i.e., embedded) references to other objects. The resulting entry objects are the expected_entries.
Make a pass through the test relationship builders supplied by the test case and use the keys in the builder to look up the ActionHash for the entry identified by that key in the IdentifierMapping table. Use those to create links.
Check that the created entries exactly match the expected entries.
Navigate relationships and confirm the target entries are as expected.
Challenge: Current Testing Strategy Inadequate for Relationships
To make it easy to assert equality between expected and actual test data, we need to create the exact test data in the fixture that we expect to be returned in during the test. But links can't be created in fixtures. How should we handle this?
Resolution: Leverage 'Keys'
In data fixtures, instead of attempting to build test data directly, focus on creating test entry builders and test relationship builders. These builders use primary keys instead of ActionHashes as identifiers.
In the Descriptors repo, type_names are primary keys, so the more sophisticated approach based on uniqueness constraints can be deferred to MAP Holons repo.
Design Summary
IdMaptables that map key strings (i.e., type_names) to ActionHashes. Probably, HolonDescriptors, ValueDescriptors, RelationshipDescriptors and DanceDescriptors can share an IdMap. Schemas could share the same map, but use name as key instead of type_name. PropertyDescriptors are basically owned by HolonDescriptors, so each HolonDescriptor can have its own PropertyDescriptor IdMap.Test Function Logic
The test functions, implement the following phases: