Add traversal.Get function #65
Conversation
| @@ -123,6 +123,26 @@ func TestFocusSingleTree(t *testing.T) { | |||
| }) | |||
| } | |||
|
|
|||
| // covers Get used on one already-loaded Node; no link-loading exercised. | |||
There was a problem hiding this comment.
a test that exercises an attempt to traverse through a link might be good, it would at least show what would be expected to occur in such a situation, I imagine it's some error that bubbles up from the bowels of Link#Load()?
There was a problem hiding this comment.
You're right, I'll add another block of tests for that. It doesn't really increase coverage, because the Focus tests that do cover link traversal hit the same spot. But it's good to be explicit in tests. And it will serve as regression testing if we ever refactored the internals in such a way that the coverage wasn't redundant, which is imaginable.
Tests for the unhappy path... uuf. I think the error handling in this whole area is overdue for some review, honestly. It's very fmt.Errorf'y at the moment, which I do not much like.
This doesn't add much in the way of coverage, since it's internally quickly convergenced with what the Focus tests cover, but in testing, explicitness is good.
|
Note/confession: The tests that cover the error paths here are asserting on the strings in the error message, rather than any well-typed information. I'd like to improve this soon -- In addition to the sheer principle of the matter, I'm writing some other tests today at an even higher level that use this package, and it's turning out deeply irritating to not have a more specific error type than |
Add
traversal.Get(andtraversal.Progress.Get), two methods which take aNodeand aPath, do a little walk, and return the reachedNode.This is a (long-overdue) helper function. It's the same functionality as has already been available through
traversal.Focus, but returns values rather than taking a callback parameter, which is more convenient in some cases.This new method also doesn't bother to accumulate Path and LastBlock info into an updated Progress object, because it doesn't return one. If the user wants the Progress info, they should continue to use Focus and a callback -- using a callback encourages clear handling of the scope of the Progress object, which should be desirable anyway.
traversal.Getdoesn't quite work for call-chaining on its own, because it potentially needs to return an error, but composes nicely with other error-redirection systems like themustpackage:must.Node(traversal.Get(startNode, ipld.ParsePath("foo/bar"))).Kind()works, for example (substitute any call you wish to chain in place of.Kind()).