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

List of tests that need to be written #54

Open
1 task
pipermerriam opened this issue Jul 6, 2023 · 5 comments
Open
1 task

List of tests that need to be written #54

pipermerriam opened this issue Jul 6, 2023 · 5 comments

Comments

@pipermerriam
Copy link
Member

pipermerriam commented Jul 6, 2023

Let's add things to this list:

@ogenev
Copy link
Member

ogenev commented Jul 7, 2023

Do we have a list of tests that need to be written?

We don't have a list right now, @KolbyML is doing a great job to implement any missing single client/two client scenario test following the JSON-RPC specs.

However, I think it is wise to have such a list especially when we switch to more complicated tests (3 and more clients).

If you have any suggestions, please write them here and we can start keeping a test list in this issue.

@KolbyML
Copy link
Member

KolbyML commented Jul 7, 2023

I can start a issue for that. Since I seem to be the main person right now on the "writing test force". There are so many tests that can be written. Especially when it comes to writing tests for scenarios since I think that is where tests will really display edge cases. So I get what @ogenev is talking about when he says 3+. For 3 client tests I believe we will get a new simulator. Since I don't think it makes sense to add those to portal-interop. So it could be a good idea to split/refactor it into "portal-interop 2 clients" then a 3 clients one.

Edit: I just read ogenev suggested we keep a test list in this I agree

@carver
Copy link
Contributor

carver commented Aug 11, 2023

Idle thought, something to add to the list of tests (portal-interop I think), if it's not already tested: retrieving receipts when there are none for a block. It would be easy for a client to mix up an empty list returned with no response, so we need to test that the two cases (no peers have the receipts available, and a peer returned the empty list of receipts) are distinguishable and returned correctly.

@carver
Copy link
Contributor

carver commented Sep 23, 2023

I guess no one has made this list. I'll just start adding things into the body of this issue.

@KolbyML
Copy link
Member

KolbyML commented Sep 23, 2023

@carver rpc-compat tests 1 node rpc's doesn't portal_historyFindNodes require 2 nodes? Also isn't what you are specifing already being tested? Maybe I am confused on what you meant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants