-
Notifications
You must be signed in to change notification settings - Fork 248
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
Put integration tests behind feature flag #515
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
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.
An alternative to the test-runtime feature-flag approach would be having the
dependency declared as optional = true and included for the feature flag only.
Unfortunately, this option does not work for dev-dependencies. Having the
test-runtime as simply dependency would cause cyclic reference.
Since tests/integration
is really it's own crate, this could be moved to the top level and made into an explicit crate which would allow using a normal dependency and make it optional
?
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
This reverts commit 8e5f38b.
|
||
Metadata::try_from(meta) | ||
Metadata::try_from(prefixed) | ||
.expect("Cannot translate runtime metadata to internal Metadata") | ||
} | ||
|
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.
// Currently the caching does not take into account different pallets
// as the intended behavior is to use this method only once.
// Enforce this behavior into testing.
let hash_old = metadata.metadata_hash(&["Balances"]);
assert_eq!(hash_old, hash);
I don't really understand what this line does? (also doesn't look like there is a balances pallet in the fake metadata?)
(alas I couldn't comment on the line itself; sorry!)
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.
Have updated the comment. If we call metadata_hash
with an argument of pallets: ["System"]
it would produce a hash that is cached internally. Therefore, if we call the same method again, but with different arguments (ie pallets: ["Balances"]
), it would fetch the previously cached value 😄
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.
Thanks, that is clearer! :)
Looks good to me offhand, and I think the separate crate is a nice organisational improvement, and gives people the opportunity to avoid the integration tests if they don't have a suitable substrate binary to hand while still making it the default, which I think is right. Just a couple of small comments and it's all good from me :) |
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
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.
How about moving the contents of integration-tests/tests/
(which at the moment is an implicit sub-crate) into integration-tests/src
(renaming main.rs
to lib.rs
?
Signed-off-by: Alexandru Vasile <[email protected]>
@ascjones Moving the |
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.
LGTM
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 good to me, nice one!
The
substrate
binary is used internally for integration testing purposes.This PR ensures that building/running tests do not rely on the existence of the
SUBSTRATE_NODE_PATH
in the environment, which is guarded under theintegration-tests
crate.The
subxt
tests that rely on the substrate binary are moved to a dedicated crate.At the same time, any dependency on the
test-runtime
is removed to avoid anycyclic dependencies. The only crate that requires the substrate binary to exist in the
environment is the
integration-tests
crate.Testing Done
Closes #351.
Next Steps
#[cfg]
is valid with feature flag