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

Fix forge scheduled tests #3003

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Fix forge scheduled tests #3003

wants to merge 5 commits into from

Conversation

ddoktorski
Copy link
Contributor

@ddoktorski ddoktorski commented Feb 26, 2025

Closes #2998

Introduced changes

  • Fix scheduled tests except cast tests, which are blocked by devnet

@ddoktorski ddoktorski marked this pull request as ready for review February 28, 2025 07:56
@ddoktorski ddoktorski requested a review from a team as a code owner February 28, 2025 07:56
@@ -288,7 +288,7 @@ pub fn assert_gas(result: &[TestTargetSummary], test_case_name: &str, asserted_g
}
AnyTestCaseSummary::Single(case) => match case {
TestCaseSummary::Passed { gas_info: gas, .. } => {
*gas == asserted_gas
asserted_gas.abs_diff(*gas) <= 1
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a different assert_gas method that uses diff and choose which one to use according to the feature? Then the scheduled tests on version other than scarb from .tool-version could use it.

E.g.

    if cfg!(feature = "non_exact_gas") {
        assert_gas_range(...) 
    else {
        assert_gas(...)
     }

I'd prefer if we still kept exact gas assertions when developing code. I know difference of 1 is not that big but we should assert exact values 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.

As discussed offline, for now leaving it as it is

Copy link
Member

Choose a reason for hiding this comment

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

I guess one thing we are losing with these changes is that we no longer assert if the max steps is sufficiently close to the default of 10m. Maybe with some logic changes we could still retain this check?

Copy link
Member

Choose a reason for hiding this comment

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

Or we could hide this check behind a feature as well, what do you think

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This has already been changed a few times and it is unmaintainable. Unfortunately, I don't have any idea for a test that will have 10m steps and for sure remain unchanged with future Cairo versions.

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 modified those tests to get the following steps values:

  • Scarb 2.8.5: 8250085 and 10200085
  • Scarb 2.10.1: 9350088 and 11560088

It seems to be close enough to test the desired behavior (failing for >10m steps - tested in should_default_to_10m test) and hopefully it won't need to be updated with the new Scarb version 🙏

Copy link
Member

Choose a reason for hiding this comment

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

Okay, we can do that

@@ -76,7 +76,7 @@ fn fuzzed_while_loop() {

// TODO (#2926)
assert_eq!(gas_info.min, 2);
assert_eq!(gas_info.max, 23);
assert!(gas_info.max.abs_diff(23) <= 1);
Copy link
Member

Choose a reason for hiding this comment

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

Same here

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.

Fix scheduled tests for 2.10.0 and rest
2 participants