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

tests: create test framework to test rpc endpoints #792 #793

Merged
merged 31 commits into from
Apr 29, 2020

Conversation

thomasmodeneis
Copy link
Contributor

@thomasmodeneis thomasmodeneis commented Apr 18, 2020

Changes

  • create test framework to test rpc endpoints as client (follow JSON-RPC Interfaces for Polkadot Nodes)

Tests:


Checklist:

  • I have read CONTRIBUTING and CODE_OF_CONDUCT
  • I have provided as much information as possible and necessary
  • I have reviewed my own pull request before requesting a review
  • I have linked any relevant issues in my pull request comments
  • All integration tests and required coverage checks are passing

Issues:

add it-stress task to Makefile
export ServerResponse from package tests/rpc
create temp config.toml for test
update stress_test.go with commented out init task that depends on #789
…0","error":{"code":-32600,"message":"json: cannot unmarshal object into Go value of type [1]interface {}","data":{}},"id":1}
add all other pending rpc endpoint test cases (skip for now)
add config.toml
add rpc tests to travis
@thomasmodeneis thomasmodeneis marked this pull request as ready for review April 20, 2020 20:52
@ryanchristo ryanchristo changed the title [WIP] create test framework to easily test all rpc endpoints as client (follow JSON-RPC Interfaces for Polkadot Nodes) #792 tests: create test framework to test rpc endpoints as client #792 Apr 21, 2020
@ryanchristo ryanchristo changed the title tests: create test framework to test rpc endpoints as client #792 tests: create test framework to test rpc endpoints #792 Apr 21, 2020
@thomasmodeneis thomasmodeneis changed the title tests: create test framework to test rpc endpoints #792 [wip] tests: create test framework to test rpc endpoints #792 Apr 21, 2020
Copy link
Member

@edwardmack edwardmack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I see that these test follow a similar pattern of setup test cases, start nodes, iterate test cases, tear down nodes. Would it make sense to create a util function that would handle start nodes, iterate and tear down, then just pass arrays of test cases to that utility?

Makefile Outdated Show resolved Hide resolved
tests/spec/empty.go Outdated Show resolved Hide resolved
Copy link
Contributor

@noot noot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good, some comments

Makefile Outdated
@@ -46,6 +46,10 @@ it-stress: build
@echo " > \033[32mRunning Integration Tests stress mode...\033[0m "
GOSSAMER_NODE_HOST=0.0.0.0 GOSSAMER_INTEGRATION_TEST_MODE=stress go test ./tests/stress/... -timeout=5m -p 1 -short -v

it-rpc: build
@echo " > \033[32mRunning Integration Tests RPC Specs mode...\033[0m "
GOSSAMER_NODE_HOST=0.0.0.0 GOSSAMER_INTEGRATION_TEST_MODE=rpc_spec go test ./tests/rpc/... -timeout=5m -p 1 -short -v
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GOSSAMER_INTEGRATION_TEST_MODE=rpc_spec

should be

GOSSAMER_INTEGRATION_TEST_MODE=rpc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So since the objective of naming it spec was to make a test suite, and you are not ok with calling it spec, but I really nice need to be something more than just rpc (since its supposed to be a test suite for the RPC endpoints that match against a test specification) I renamed the logs to RPC suite. Let me know if you have any objections.

)

func TestMain(m *testing.M) {
_, _ = fmt.Fprintln(os.Stdout, "Going to start RPC spec test")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove spec

Copy link
Contributor Author

@thomasmodeneis thomasmodeneis Apr 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So since the objective of naming it spec was to make a test suite, and you are not ok with calling it spec, but I really nice need to be something more than just rpc (since its supposed to be a test suite for the RPC endpoints that match against a test specification) I renamed the logs to RPC suite. Let me know if you have any objections.

)

func TestSystemRPC(t *testing.T) {
if GOSSAMER_INTEGRATION_TEST_MODE != rpcSpec {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change rpcSpec to rpc

Copy link
Contributor Author

@thomasmodeneis thomasmodeneis Apr 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So since the objective of naming it spec was to make a test suite, and you are not ok with calling it spec, but I really nice need to be something more than just rpc (since its supposed to be a test suite for the RPC endpoints that match against a test specification) I renamed the logs to RPC suite. Let me know if you have any objections.


t.Log("Will start assertion for ", "target", target, "type", reflect.TypeOf(target))

switch v := target.(type) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we switch on the test description? what if an rpc method returns the wrong type

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RPC method should never return the wrong type, if that is happening we are in deep trouble.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay well this will panic if it returns the wrong type, is that the desired behaviour?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would it panic ? it just not going to match any type. If something else is going on with the endpoint it will be either captured at unit tests or on DecodeRPC method

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is also the require nil err just before the switch...if you happen to be able to prove the edge case you are mentioning I will be more than happy to enforce more rules. Right now it seems like a overkill...

Copy link
Contributor

@noot noot Apr 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking at the DecodeRPC method, the switch statement seems very brittle and will need to be updated in case the RPC api changes. it would be better to pass in a target interface{} directly instead of targetType string and switching on it. maybe we could open an issue for that, or do you want to change it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, that one should be always updated. That is why this is going to be part of the CI.
The trick is that the DisallowUnknownFields will make it fail nicely if the endpoint return changes, so we will see the test failures beforehand.

case *modules.SystemHealthResponse:
t.Log("Will assert SystemHealthResponse", "target", target)

require.Equal(t, test.expected.(modules.SystemHealthResponse).Health.IsSyncing, v.Health.IsSyncing)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this line could potentially panic - for example, say system_networkState returns a SystemHealthResponse for some reason (there are probably better examples in the other modules but this is these are the only ones implemented so far)
then, test.expected is SystemNetworkStateResponse, not SystemHealthResponse. then, the type conversion test.expected.(modules.SystemHealthResponse) will panic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it should not return that, I mean, why would the system_networkState return a type that belongs to the other endpoint ? that should be captured at the unit test level. This are integration tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are assuming here, that the minimum tests have been already checked by proper unit testing. Again, if this is happening at the integration tests and we have a panic, that is a good thing to happen. At least we will know right away something is really broken.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay I just think it's good practice to always do an a, ok := b.(mytype) to avoid potential panics, it also seems to make more sense to switch on the test description or method name instead of the expected type, but if you prefer it this way

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, raised #815 to tackle this!

@thomasmodeneis thomasmodeneis merged commit 8491803 into development Apr 29, 2020
@thomasmodeneis thomasmodeneis deleted the thomas/feature-792 branch April 29, 2020 14:42
ryanchristo pushed a commit that referenced this pull request Jun 24, 2020
create test framework to test rpc endpoints as client (follow JSON-RPC Interfaces for Polkadot Nodes)
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

Successfully merging this pull request may close these issues.

None yet

4 participants