High level integration tests

[elliotcmorris]

Closes #12

Add a set of high level integration tests, and data to go with them. All they do is load a USD stage, then verify that it manages to find the properties of the branch prims.

These tests assert the basic workflow of loading a USD document with resolvable references in it, as well as that the OpenAssetIO resolver dosen't override or interfere with USD standard resolution mechanisms.

For any test dataset that expects OpenAssetIO to resolve a LocatableContent trait, a BAL format library has been included with the dataset to document that path strings that should be returns, although no effort has been made to integrate OpenAssetIO or BAL, the formatting choice is purely speculative.

[feltech]

As a side note - we generally have been using the when/then form for test names. Be good to align on which we prefer. I kind of like this approach in many ways as it moves the when/then into a comment which has more space than <99 chars.

Elaborating in comments is a good idea, I like that. But the test function names are what is shown in the pytest output, so I think are worth keeping as descriptive as possible.

As an aside, I'm pretty sure the unittest runner will print docstrings rather than method names, if available. But pytest doesn't. A quick google finds some pytest plugins though, which may be worth a look.

[elliotcmorris]

As a side note - we generally have been using the when/then form for test names. Be good to align on which we prefer. I kind of like this approach in many ways as it moves the when/then into a comment which has more space than <99 chars.

Elaborating in comments is a good idea, I like that. But the test function names are what is shown in the pytest output, so I think are worth keeping as descriptive as possible.

I think you'd get some really absurdly long method names if you were to do that in these cases, I did try initially. I think the names are pretty descriptive as they are, just shortened from the full given;and;then framing. That would also propagate to give some really long data folder names to match, (although arguably that's not a neccesary connection)

[feltech]

As a side note - we generally have been using the when/then form for test names. Be good to align on which we prefer. I kind of like this approach in many ways as it moves the when/then into a comment which has more space than <99 chars.

Elaborating in comments is a good idea, I like that. But the test function names are what is shown in the pytest output, so I think are worth keeping as descriptive as possible.

I think you'd get some really absurdly long method names if you were to do that in these cases, I did try initially. I think the names are pretty descriptive as they are, just shortened from the full given;and;then framing. That would also propagate to give some really long data folder names to match, (although arguably that's not a neccesary connection)

To be fair, we also say that when/then style is only really useful in cases where there are multiple branches. In these cases, you could possibly write a when (though it would indeed be wordy), but the then is always the same so is a bit redundant.

I'm happy in this case to have the test case name essentially describe the dataset. If a test fails, then that would make it pretty easy to tell what functionality was broken at a glance.

[elliotcmorris]

Changes based on pivots discussed offline, not longer allowing relative file path from resolver.

a682351

a38c6af

[feltech]

Changes based on pivots discussed offline, not longer allowing relative file path from resolver.

a682351

a38c6af

Unfortunately GitHub aggressively prunes branches after a force-push, so those commits are no longer available. Think I can compare locally though.

[elliotcmorris]

Unfortunately GitHub aggressively prunes branches after a force-push, so those commits are no longer available. Think I can compare locally though.

Yeah sorry David, in a bit of a race to hit the button on this one, thought those commits could be taken as read.