According to Exception messages in POV:
# when a path cannot be found between a start and end node on the tree.
raise ValueError("No path found")
However, test_errors_if_source_does_not_exist expects "Tree could not be reoriented". That error message has this comment:
# when a tree cannot be oriented to a new node POV
I think the following change needs to be made to the documentation (or something similar):
# when a tree cannot be oriented to a new node POV or the start node of a path cannot be found
raise ValueError("Tree could not be reoriented")
# when the end node of a path cannot be found
raise ValueError("No path found")
I think that an assumption is being made about how the exercise will be implemented such that the from_pov method will be implemented first, and then the to_path method will use that to find the path from the start to the end node. I, instead, chose to implement the to_path method first since I knew how to solve that, and I’m planning on using to_path to solve from_pov.
Hi @rzuckerm 
POV is a practice exercise that draws its problem description and test data from a common cross-track repository called problem specifications.
The exercise on the Python track is auto-generated from the problem specs repo using a JinJa2 template. Test order is derived from the canonical data order.
Suggestions for improving the exercise/test data, should be made under problem specifications, so that all tracks can benefit from the discussion.
As for the Python track instruction append, I will take a look.
IIRC, that instruction and its comments were to serve as a warning that we check the content of the error message when it’s raised (and so it has to match exactly). It was not intended to be a directive on which method to implement in which order.
So perhaps the solution is not more specificity, but less. In any case, when I have time I will review it. 
Hi @BethanyG ,
Thanks for giving me an insight into the intricate process of how exercises are put together for the various language tracks.
The exercise on the Python track is auto-generated from the problem specs repo using a JinJa2 template. Test order is derived from the canonical data order.
I found the test template here and the instructions that are appended to the exercise page here. It seems like all that would have to be done is just to change the descriptions for the two raise statements in that Markdown document. I’m not sure how this applies to other language tracks since other languages would have different ways of raising exceptions (or whatever the equivalent is in that language).
Hi @rzuckerm,
I think you may have missed the lede here (emphasis mine).
So perhaps the solution is not more specificity, but less. In any case, when I have time I will review it.
Frankly, given the difficulty rating of the exercise and where it appears on the track, I am tempted to remove the raise() examples altogether.
Yes, it was a difficult exercise. It took me several days to figure out. As for changing the error messages, there was another exercise that didn’t specify the error message, and the test just made sure that the error message was not empty. That seems fine.
