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

(test): Functions foundry tests use OCR contracts & a higher tx.gasprice #10635

Merged
merged 5 commits into from
Sep 18, 2023

Conversation

justinkaseman
Copy link
Contributor

No description provided.

@github-actions
Copy link
Contributor

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

s_subscriptionId,
5500
);
/// @dev Overload to give transmitterGasToUse as 0, which gives default tx gas
Copy link
Contributor

@KuphJr KuphJr Sep 15, 2023

Choose a reason for hiding this comment

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

This is better than before, but still has a lot of repeated code. Is there a better way to structure this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we have a single _reportAndStore and just pass the required args every time?

Copy link
Contributor Author

@justinkaseman justinkaseman Sep 15, 2023

Choose a reason for hiding this comment

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

a lot of repeated code

Like what? The only repeated code I see is the fulfillment data, but I think that's better to not re-use

Copy link
Contributor Author

@justinkaseman justinkaseman Sep 15, 2023

Choose a reason for hiding this comment

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

Can we have a single _reportAndStore and just pass the required args every time?

This will make it harder to read & write the test case itself.
If the overloaded function is used, then the args are filled in by it aren't relevant to the test.

I'm open to making this change though if you think it will make it easier to grok
How about having a natspec on the overloaded ones that say what was filled in?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes that would help. I just want to make sure I able to grok everything during review and I got a bit confused during the overloaded funcs

s_subscriptionId,
5500
);
/// @dev Overload to give transmitterGasToUse as 0, which gives default tx gas
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we have a single _reportAndStore and just pass the required args every time?

entriesAfterRequest2[0].data,
(address, uint64, address, bytes, uint16, bytes32, uint64, FunctionsResponse.Commitment)
function _reportAndStore(
uint256[] memory requestNumberKeys,
Copy link
Contributor

Choose a reason for hiding this comment

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

What is requestNumberKeys?

Copy link
Contributor Author

@justinkaseman justinkaseman Sep 15, 2023

Choose a reason for hiding this comment

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

That's just the internal key for where to find the request in the test environment state s_requests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could add natspec docs to the helpers if that would help

Copy link
Contributor

@KuphJr KuphJr left a comment

Choose a reason for hiding this comment

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

I'm finding the various _reportAndStore() functions a bit difficult to reason about as I keep having to switch back and forth between Setup.t.sol and FunctionsRouter.t.sol to see what each overloaded function is supposed to do.

@justinkaseman justinkaseman force-pushed the FUN-734-foundry-tests-6 branch from 0e798c5 to 62bb674 Compare September 15, 2023 17:07
KuphJr
KuphJr previously approved these changes Sep 15, 2023
Copy link
Contributor

@KuphJr KuphJr left a comment

Choose a reason for hiding this comment

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

Thanks for the additional comments!

KuphJr
KuphJr previously approved these changes Sep 18, 2023
@cl-sonarqube-production
Copy link

SonarQube Quality Gate

Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@justinkaseman justinkaseman added this pull request to the merge queue Sep 18, 2023
Merged via the queue into develop with commit 6e86a70 Sep 18, 2023
122 of 123 checks passed
@justinkaseman justinkaseman deleted the FUN-734-foundry-tests-6 branch September 18, 2023 20:18
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.

2 participants