Difference between revisions of "User:Infinity Linden/OGP Test Cases"
| Line 11: | Line 11: | ||
The objective of the Open Grid Protocol is to specify syntax and semantics of SL Grid messages to the degree that interoperable viewers, agent domains, region domains and regions may be coded without resort to close examination of open source code from Linden Lab or peeking into the interaction between running clients and servers. The Second Life Grid has been developed sufficiently, the reasoning goes, that it should be possible to shine the bright light of inquiry on the process and document the living heck out of how the system works. Moving forward we should see advantages as software developers code to documented requirements and standards. The "OGP Test Cases" are a catalog of tests that demonstrate compatibility with the written spec. | The objective of the Open Grid Protocol is to specify syntax and semantics of SL Grid messages to the degree that interoperable viewers, agent domains, region domains and regions may be coded without resort to close examination of open source code from Linden Lab or peeking into the interaction between running clients and servers. The Second Life Grid has been developed sufficiently, the reasoning goes, that it should be possible to shine the bright light of inquiry on the process and document the living heck out of how the system works. Moving forward we should see advantages as software developers code to documented requirements and standards. The "OGP Test Cases" are a catalog of tests that demonstrate compatibility with the written spec. | ||
Well... that's how it's supposed to be... | Well... that's how it's supposed to be... In the real world, "running code" trumps written specifications, and probably will continue to do so. And that's one of the reasons we have the interop tests; properly written test cases succinctly communicate abstractions introduced in written specifications. So rather than viewing the SLGOGP spec and these tests as separate, think of them as being two sections of the same document. | ||
= Base Tests = | |||
== REST Tests == | |||
== LLSD (Linden Lab Structured Data) == | |||
= | == Event Queue == | ||
== Capabilities == | |||
= Resource Tests = | |||
== Agent Credential == | |||
== Account Credential == | |||
= Login Tests = | = Login Tests = | ||
Login is the process of associating a viewer with an agent domain, then placing the user's avatar in a region managed by a (potentially separate) region domain. The spec describes logging in as the sequence: | |||
# The viewer authenticates to an agent domain for the authorized control of a particular agent. | |||
# The viewer directs the agent domain to to place the agent in a region. | |||
# The agent domain contacts the region domain for the region, and negotiates placement of the agent. | |||
# The region grants access to the agent domain, which in turn passes some of that granted access on to the viewer. | |||
Testing the login process means logging each of these steps, in order. We should also test that executing them out of order leads to an error. | |||
We assume the code providing underlying services (such as the event queue, LLSD serialization / deserialization, MD5 Hash production, etc.) is reliable and has been tested. | |||
{|style="background:white" width="100%" cellpadding="5" | |||
|- style="background:lightgrey;" | |||
| colspan="3" | '''Viewer to Agent Domain Authentication Tests''' | |||
|- style="background:lightgrey;" | |||
| | |||
| '''expecting?''' | |||
| '''test description''' | |||
|- style="background:lightgrey;" | |||
| | |||
| success | |||
| authenticate to agent domain using good agent name and password | |||
|- style="background:lightgrey;" | |||
| | |||
| success | |||
| authenticate to agent domain using good account name and password, where account name maps to a single agent name | |||
|- style="background:lightgrey;" | |||
| | |||
| failure | |||
| authenticate to agent domain using good account name and password, where account name maps to a multiple agent names | |||
|- style="background:lightgrey;" | |||
| | |||
| failure | |||
| authenticate to agent domain using known account name but bad password | |||
|- style="background:lightgrey;" | |||
| | |||
| failure | |||
| authenticate to agent domain using unknown account name | |||
|} | |||
= Teleport Tests = | = Teleport Tests = | ||
Revision as of 13:57, 15 July 2008
note: this is a brief note for informational purposes. it's eventually going to be "cleaned up" and moved to a more appropriate place on this wiki.
Introduction
What is This?
In the development of the Open Grid Protocol and the PyOGP project, it became obvious that there were no canonical lists of use cases and things to test. This page is the first effort to remediate this omission. While we don't go as far as providing use cases here, we do list common functionality and interoperability tests.
About the OGP Test Cases
The objective of the Open Grid Protocol is to specify syntax and semantics of SL Grid messages to the degree that interoperable viewers, agent domains, region domains and regions may be coded without resort to close examination of open source code from Linden Lab or peeking into the interaction between running clients and servers. The Second Life Grid has been developed sufficiently, the reasoning goes, that it should be possible to shine the bright light of inquiry on the process and document the living heck out of how the system works. Moving forward we should see advantages as software developers code to documented requirements and standards. The "OGP Test Cases" are a catalog of tests that demonstrate compatibility with the written spec.
Well... that's how it's supposed to be... In the real world, "running code" trumps written specifications, and probably will continue to do so. And that's one of the reasons we have the interop tests; properly written test cases succinctly communicate abstractions introduced in written specifications. So rather than viewing the SLGOGP spec and these tests as separate, think of them as being two sections of the same document.
Base Tests
REST Tests
LLSD (Linden Lab Structured Data)
Event Queue
Capabilities
Resource Tests
Agent Credential
Account Credential
Login Tests
Login is the process of associating a viewer with an agent domain, then placing the user's avatar in a region managed by a (potentially separate) region domain. The spec describes logging in as the sequence:
- The viewer authenticates to an agent domain for the authorized control of a particular agent.
- The viewer directs the agent domain to to place the agent in a region.
- The agent domain contacts the region domain for the region, and negotiates placement of the agent.
- The region grants access to the agent domain, which in turn passes some of that granted access on to the viewer.
Testing the login process means logging each of these steps, in order. We should also test that executing them out of order leads to an error.
We assume the code providing underlying services (such as the event queue, LLSD serialization / deserialization, MD5 Hash production, etc.) is reliable and has been tested.
| Viewer to Agent Domain Authentication Tests | ||
| expecting? | test description | |
| success | authenticate to agent domain using good agent name and password | |
| success | authenticate to agent domain using good account name and password, where account name maps to a single agent name | |
| failure | authenticate to agent domain using good account name and password, where account name maps to a multiple agent names | |
| failure | authenticate to agent domain using known account name but bad password | |
| failure | authenticate to agent domain using unknown account name | |