Open pospi opened 2 years ago
@pospi I am thinking about this...
what about actually adding this to hdk_unit_testing
crate? I am thinking about taking it on, and doing a full pass
The helper macros? Sure, if you want to. I would have logged something to split them out for reuse later anyways.
I basically wanted to wrap up some abstractions so that there were simple ways of wiring up mocks at the same layer of abstraction as the HDK client library. So basically, if there is a method for get_entry
that accepts an EntryHash
and returns some typed Entry
then there should also be an easy way of setting up a mock that allows me to simply wire up function inputs to function outputs.
I suppose hash_entry
and other things where the hash is an implementation detail that doesn't need to be anything other than some unique data are the exception. That's why eg. mock_path
doesn't require you to specify anything about the hashes of the Path and creates fixtures for those internals for you.
Maybe to avoid possible friction while they're in development it would be best to do the work here for now, and we can split out the git history and merge it into the external library later?
Yeah, I share your goal of having the things that you can call be equal to the HDK function signatures. I'm fine either way, I'll see what looks like is making sense when I am gearing up for actually doing the work.
I unassigned you and assigned myself since this is coming hand-in-hand with the #275
Some starting work has been done on this as part of #268, but it needs to be worked through in order to achieve #85 since the logic is quite complicated and will need to be unit tested in isolation.
This is basically a case of completing the test helper macros in https://github.com/h-REA/hREA/blob/sprout/lib/hdk_time_indexing/tests/src/helper_macros.rs to a usable standard for testing the indexing DHT ops.