Extend Test Cases to Cover Holochain Storage Lifecycle

[dauphin3]

actually leverage the DHT via mock conductor to create HC entries and retrieve them by hash

[evomimic]

This issue focuses on testing the already generated code for creating, updating, deleting, and getting HolonDescriptors and PropertyDescriptors from the holochain DHT.

Desired tests:

• [x] create_holon_descriptor
• [x] get_holon_descriptor (and confirm we are able to get exactly the descriptor we just created)
• [x] get_all_holon_types
• [x] update_holon_descriptor (and confirm we are able to get exactly the descriptor we just updated)
• [x] delete_holon_descriptor (and confirm delete)
• [x] create_property_descriptor
• [x] get_property_descriptor (and confirm we are able to get exactly the descriptor we just created)
• [x] get_all_property_types
• [x] update_property_descriptor (and confirm we are able to get exactly the descriptor we just updated)
• [x] delete_property_descriptor (and confirm delete)

Some guidelines:

1. Put each test in its own .rs file within the coordinator tests folder.
2. Avoid making changes to the query and storage functions generated by the scaffold tool
3. Leverage the stub_data_creator to create the data used by create_holon_descriptor

[evomimic]

I've had a chance to think more deeply about the MAP Descriptors test strategy. Here are a few observations:

Get and Create Functions:

• To verify a "get" we need to first "create" the record
• To verify a "create", we need follow the create with a "get"
• So... we don't really need independent tests of both.
• Conclusion: Omit separate "Get" tests.

Creating Many Holon Descriptors

• Creating many descriptors depends on creating a single descriptor -- by iterating through a vector of HolonDescriptors we are doing a series of individual creates.
• Conclusion: We don't need a separate test for single creates vs. multiple creates

Functions are the same, what varies it the data

• The logic for CUD tests is identical, what varies is the test data.
• BUT... if the test data set has all testable different variations in it, we may only need 1 test data set

Restructuring

So I've restructured things as follows:

• expand the _stub_datacreator.rs file to create a rich test dataset by creating a vector of HolonDescriptors of various kinds -- from simple to complex
• create a single _holon_descriptortests.rs in the crates/coordinator/descriptors/tests directory that takes advantage of the rich dataset to walk through a series of steps: -- it exercises the following holon_descriptor API functions: get_all_holon_types() (both before and after creating holon descriptors), create_holon_descriptor(), get_holon_descriptor(), (and eventually, delete_holon_descriptor() and update_holon_descriptor())

Implications

• Everything will run as one (sequential) test. We don't get the advantages of parallel test execution.
• Cargo treats this as one test that only passes if EVERY test succeeds. If any internal test fails, we need to know which test failed.
• Conclusion: Include println!'s to record testing progress. By default, cargo test only shows stdout on failures. So the intermediate results are only shown if some test fails.

To always see the testing progress, use cargo test -- --show-output

We can follow a similar approach to structuring property_descriptor_tests.