Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase test coverage of MatrixTransport #3124

Closed
9 of 15 tasks
LefterisJP opened this issue Dec 5, 2018 · 3 comments
Closed
9 of 15 tasks

Increase test coverage of MatrixTransport #3124

LefterisJP opened this issue Dec 5, 2018 · 3 comments
Assignees
Labels

Comments

@LefterisJP
Copy link
Contributor

LefterisJP commented Dec 5, 2018

Problem Definition

Even though the MatrixTransport has a test coverage of > 70% most of that is incidental through the integration tests.

We assumed that the integration tests would be enough to thoroughly test the transport, but it turns out that this assumption was mistaken.

We need specific tests that exercise esp. the unhappy and edge cases.

Some groundwork in that direction has already been laid with #3172 (and the accompanying tests)

Tests to write

  • Hanging transfers (Fix hanging transfers #3123)

    • Test the invite works on the happy path (both users online):
    • Test the invite works on the unhappy paths:
      • Both nodes open an invite at the same time
      • The node which is being invited is offline at the time of the invite
      • The node which does the invite goes offline and the invited node comes back online
  • User roaming

    • Write test that ensures users switching servers are handled correctly
      • User A uses server X and performs a transfer with User B.
      • User A uses server Y and performs a transfer with User B.
      • User A comes back to server X and performs a transfer with User B.
      • Repeat for both users roaming across servers
  • Account data update (Payments wait forever to be conducted #2779)

    • Test that a single update to account data are stored in the matrix server
    • Test the single update is recovered on restarts
    • Test that concurrent updates don't race, and that the latest one will be respected and loaded on the following restart (we need a definition of order here, @andrevmatos @ulope ?)
  • Misbehaving servers

    • Test that the transport can cope with misbehaving servers (e.g. HTTP codes 4xx, 5xx). The client should either catch such errors and retry the operation or crash with descriptive error
  • Retries

    • Write tests that ensure retries work correctly even after re-starting and also with roaming users (see above)
@LefterisJP LefterisJP added this to the Red Eyes Testnet 19 milestone Dec 5, 2018
@LefterisJP LefterisJP added the P1 label Dec 5, 2018
@LefterisJP LefterisJP modified the milestones: Red Eyes Testnet 20, Next Release Jan 1, 2019
@ulope ulope added the Component / Transport Transport related issues label Jan 21, 2019
@ulope ulope changed the title Write Unit and Integration Tests for Matrix Increase test coverage of MatrixTransport Jan 21, 2019
@ulope
Copy link
Collaborator

ulope commented Jan 21, 2019

@hackaugusto I pulled your suggested tests into the issue description

@raiden-network raiden-network deleted a comment from hackaugusto Jan 21, 2019
@raiden-network raiden-network deleted a comment from hackaugusto Jan 21, 2019
err508 pushed a commit to err508/raiden that referenced this issue Feb 4, 2019
err508 pushed a commit to err508/raiden that referenced this issue Feb 5, 2019
err508 pushed a commit to err508/raiden that referenced this issue Feb 5, 2019
err508 pushed a commit to err508/raiden that referenced this issue Feb 5, 2019
err508 pushed a commit to err508/raiden that referenced this issue Feb 5, 2019
err508 pushed a commit to err508/raiden that referenced this issue Feb 5, 2019
err508 pushed a commit to err508/raiden that referenced this issue Mar 8, 2019
condition:
- Client A invites
- The invite triggers _handle_invite in Client B's transport
- Client A starts sending messages to Client B
- Messages are lost, as the invite was not processed yet

The race condition will be fixed in another PR.
Appeared during raiden-network#3124, related raiden-network#2779, raiden-network#3123.
err508 pushed a commit to err508/raiden that referenced this issue Mar 13, 2019
condition:
- Client A invites
- The invite triggers _handle_invite in Client B's transport
- Client A starts sending messages to Client B
- Messages are lost, as the invite was not processed yet

The race condition will be fixed in another PR.
Appeared during raiden-network#3124, related raiden-network#2779, raiden-network#3123.
err508 pushed a commit to err508/raiden that referenced this issue Mar 14, 2019
condition:
- Client A invites
- The invite triggers _handle_invite in Client B's transport
- Client A starts sending messages to Client B
- Messages are lost, as the invite was not processed yet

The race condition will be fixed in another PR.
Appeared during raiden-network#3124, related raiden-network#2779, raiden-network#3123.
err508 pushed a commit to err508/raiden that referenced this issue Mar 18, 2019
err508 pushed a commit to err508/raiden that referenced this issue Mar 18, 2019
condition:
- Client A invites
- The invite triggers _handle_invite in Client B's transport
- Client A starts sending messages to Client B
- Messages are lost, as the invite was not processed yet

The race condition will be fixed in another PR.
Appeared during raiden-network#3124, related raiden-network#2779, raiden-network#3123.
err508 pushed a commit to err508/raiden that referenced this issue Mar 27, 2019
err508 pushed a commit to err508/raiden that referenced this issue Mar 27, 2019
condition:
- Client A invites
- The invite triggers _handle_invite in Client B's transport
- Client A starts sending messages to Client B
- Messages are lost, as the invite was not processed yet

The race condition will be fixed in another PR.
Appeared during raiden-network#3124, related raiden-network#2779, raiden-network#3123.
err508 pushed a commit that referenced this issue Mar 27, 2019
ulope added a commit to ulope/raiden that referenced this issue Apr 18, 2019
- Extract the user/address mapping and presence handling into a separate
  utility class (`UserAddressManager`)
- This allows the services to use this functionality as well (Fixes raiden-network#3720)
- Complete unit test coverage of the new `UserAddressManager`

Refs: raiden-network#3124, raiden-network#3252
ulope added a commit to ulope/raiden that referenced this issue Apr 25, 2019
- Extract the user/address mapping and presence handling into a separate
  utility class (`UserAddressManager`)
- This allows the services to use this functionality as well (Fixes raiden-network#3720)
- Complete unit test coverage of the new `UserAddressManager`

Refs: raiden-network#3124, raiden-network#3252
ulope added a commit to ulope/raiden that referenced this issue Apr 25, 2019
- Extract the user/address mapping and presence handling into a separate
  utility class (`UserAddressManager`)
- This allows the services to use this functionality as well (Fixes raiden-network#3720)
- Complete unit test coverage of the new `UserAddressManager`

Refs: raiden-network#3124, raiden-network#3252
ulope added a commit that referenced this issue Apr 25, 2019
- Extract the user/address mapping and presence handling into a separate
  utility class (`UserAddressManager`)
- This allows the services to use this functionality as well (Fixes #3720)
- Complete unit test coverage of the new `UserAddressManager`

Refs: #3124, #3252
@rakanalh rakanalh modified the milestones: Next Release, Ithaca Jun 24, 2019
@palango
Copy link
Contributor

palango commented Aug 23, 2019

@ulope I think you worked a lot on testing more. Can this be closed or should it be left open?

@LefterisJP
Copy link
Contributor Author

Let's just close it, since this has been open a long time and has no specific coverage target.

@ulope what you think?

@palango palango removed this from the Alderaan milestone Sep 2, 2019
@rakanalh rakanalh removed the P1 label Oct 28, 2019
@karlb karlb closed this as completed Sep 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants