-
Notifications
You must be signed in to change notification settings - Fork 111
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
Conversation
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
…as/feature-741-stress
…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
fix init / startup
fix call to Get HighestBlockHash and related assert
…amer into thomas/feature-792
There was a problem hiding this 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?
There was a problem hiding this 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
…es than planned but should be good now
…es than planned but should be good now
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
tests/rpc/rpc_00_test.go
Outdated
) | ||
|
||
func TestMain(m *testing.M) { | ||
_, _ = fmt.Fprintln(os.Stdout, "Going to start RPC spec test") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove spec
There was a problem hiding this comment.
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.
tests/rpc/rpc_01-system_test.go
Outdated
) | ||
|
||
func TestSystemRPC(t *testing.T) { | ||
if GOSSAMER_INTEGRATION_TEST_MODE != rpcSpec { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change rpcSpec to rpc
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!
Changes
Tests:
Checklist:
Issues: