search

hyperledger-archives / aries-protocol-test-suite

Test Suite for testing protocol compliance of Aries Agents
https://wiki.hyperledger.org/display/aries
Apache License 2.0
25 stars 19 forks source link

Add BasicMessage tests #24

Closed dbluhm closed 4 years ago

dbluhm commented 4 years ago

Tested against ACA-Py with a quickly hacked together backchannel.

@smithbk if you're able and have an agent that supports BasicMessage, I'm interested to hear your experience with these tests.

smithbk commented 4 years ago

@dbluhm Daniel, my agent does support basic message but don't have time right now to try to use it. But from looking, I think the backchannel definition should be as follows. The 'verkey' arg is needed for all protocols flowing over a connection to identify to the agent under test which connection to use. And I think passing in the id of the message sent makes it easier for a receiver agent-under-test to implement the get_message call.

    async def basic_message_v1_0_send_message(self, verkey: str, content: str) -> str:
        """Send a message over the connection associated with verkey.  Return the id of the message."""
        raise NotImplementedError()

    async def basic_message_v1_0_get_message(self, verkey: str, id: str) -> str:
        """Return the contents of the message received over the connection associated with verkey and whose message id is 'id'."""
        raise NotImplementedError()
dbluhm commented 4 years ago

The 'verkey' arg is needed for all protocols flowing over a connection to identify to the agent under test which connection to use. And I think passing in the id of the message sent makes it easier for a receiver agent-under-test to implement the get_message call.

I definitely agree that including the message ID is a good idea. And that is a good point about needing some way of indicating to the agent under test which connection we're talking about. There are of course differences, though, among agent implementations in how they identify connections; ACA-Py for instance uses a UUID. In my testing against ACA-Py, I had my backchannel hold on to a single connection ID as the "active connection," which worked well enough in this case but might not work as well when we need tests that simulate multiple connections. I'll do some thinking and see if there is perhaps a better way for us to let the Backchannel implementation determine the selector for a given implementation. Using the verkey with a mapping to the agent-specific identifier does feel like one of the simplest options.

dbluhm commented 4 years ago

Given that it includes both a DID and a verkey, I think I'm leaning towards passing the entire connection object to the backchannel which can then determine what information it wants to use as a connection selector from there. Any objections to that approach?

smithbk commented 4 years ago

Yeh, that sounds good but I think we should be consistent. I already used verkey for discover-features so you want to change that as well?

dbluhm commented 4 years ago

Yes, +1 for consistency. I'd be happy to contribute that.

TelegramSam commented 4 years ago

@dhh1128 What do you think is the right approach for testing here? I'm nervous that requiring error reports via the tests will end up with the same issues as the interactive protocols being included in an Aries Interop Profile.