The test was originally implemented when version 1.25 of the XEP was the most current version. Later versions of the XEP do significantly modify the specifications, but the test implementation has had continuous changes over time too. This makes it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.2.1
The test was originally implemented when version 0.5.1 of the XEP was the most current version. The Smack code that is being tested defines a namespace that was introduced in 0.6, making it plausible that this implementation matches the version of the XEP, followed by some editorial changes: 0.6.3 (which is _not_ the latest version of the XEP).
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.1.
The test was implemented when version 0.4 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 0.5.1.
The test was implemented when version 0.3.1 of the XEP was the most current version. The Smack code that is being tested defines a namespace that was introduced in 0.4.0, making it plausible that this implementation matches that version of the XEP: 0.4.0 (which is _not_ the latest version of the XEP).
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.9.
The test was implemented when version 1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.3.1.
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.3.0.
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 2.1.
The test was implemented when version 1.5.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.6.0.
An optional configuration option for the Smack Integration Test framework has been added that allows one to bypass DNS when resolving a host for the XMPP domain that is the subject of the test.
The `host` option can be used with IP addresses (eg: `-Dsinttest.host=127.0.0.1`) and DNS names (eg: `-Dsinttest.host=example.org`).
This tests reliably fails, not only for me. I suspect that it is
related to the order of events checked by this tests, that can not be
reliably tested, even with sync listeners.
It is also is primarily a test for server behavior.
In order to be able to identify potential room leaks, use unique rooms
names for the two integration tests. Also destroy the room in
mucJoinSemiAnonymousRoomReceivedByNonModeratorTest().
Only declare the body of the participant listeners once. And increase
the try block, to account, for example, for
participantOneSeesTwoEnter.waitForResult() throwing.
MUCUser.getStatus() returns a set, checking if a particular MUC status
number is set should be done via a simple and efficient set operation
and not by resorting to using Java's stream API.
This method only had one call site and using such "helper" methods has
the drawback that it is not immediatly obvious what it does when
reading the integration test code. Therefore, we better inline it.
When comparing SINT-configuration to annotations, a bit of normalization occurs, to ensure that common variations in denoting a specification are detected to be equal to each-other.
The dash (`-`) character is commonly used when referencing a specification (eg: `XEP-0001`).
This commit ensures that usage of a dash (`-`) character is included in the normalization process, making `XEP 0001`, `XEP0001` and `XEP-0001` all to be identified as the same reference.
Some specifications are versioned. XEPs, for example, typically are. It is useful to annotate an implementation with the specific version of the specification that is being tested.
The default set of packages that is scanned for integration tests are referencing jivesoftware. This commit adds igniterealtime-oriented package names.
The implementation of the test that is being removed depends on a server
characteristic that will cause a loop of presence stanzas (which obviously is
bad). A RFC3921-compliant client can send an 'acknowledgement' after receiving
a presence 'subscribed' stanza, in the form of a presence 'subscribe' stanza.
See section 8.2 of RFC3921.
When a server implementation does not ignore this acknowledgement, the domain
of the recipient MUST (RFC6121 section 3.1.3) respond with a 'subscribed' on
behalf of the recipient (which is what the now removed test was verifying).
This can trigger the RFC3921-compliant sender to again receive 'subscribed',
that it again can acknowledge, which causes a loop.
To test RFC6121, the subscription state of the recipient must somehow be
modified to reflect a different state than that of the initiator. I'm not sure
if that is feasible with the SINT framework.
