bug(`forge test`): table tests only capture last iteration's console logs and gas snapshots

[die-herdplatte]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

1.3.0-nightly 56b806a

What version of Foundryup are you on?

1.3.0

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

Hey,

I don't know if this is intentional, but with the following test contract, console logs are only emitted for the last iteration.

pragma solidity ^0.8.30;

import {Test} from "forge-std/Test.sol";
import {console} from "forge-std/console.sol";

contract MyTest is Test {
    function fixtureStr() public pure returns (string[2] memory strings) {
        strings[0] = "first";
        strings[1] = "second";
    }

    function tableStrTest(string memory str) public pure {
        console.log(str);
    }
}

Running forge test:

[PASS] tableStrTest(string) (gas: 3464)
Logs:
  second

The same thing also applies to gas snapshots, where only snapshots made in the last iteration are recorded.

Potential code section that causes this behavior: https://github.com/grandizzy/foundry/blob/887a282cca0fd1c38072fa8e1ede896d06c7b94c/crates/forge/src/runner.rs#L670-L675

[grandizzy]

@die-herdplatte yeah, that's inline with fuzz and invariant test (though on fuzz you can specify / config the number of gas samples to collect and if you want to show logs for every run)

[die-herdplatte]

Oh ok, if fuzz tests have those configuration options, then I think they should also exist for table tests.
For now I fell back to a for loop over my dataset so that each log and gas snapshot is recorded.

[bbjubjub2494]

I can confirm I ran into the same issue recently. I had to find a workaround to get nice snapshots

https://github.com/randa-mu/bls-solidity/blob/c462c03f612190d9ac4d487c70730fb6df79151e/test/BLSTest.sol#L60

It's not very intuitive, although there's no obvious correct behavior there either.

This also affects forge coverage, causing the system to falsely report lines and branches as not covered at all if they were not covered in the last iteration. Here IMHO it's more obvious what the correct behavior is: the coveredness should be inclusive or'd between table rows

[grandizzy]

@die-herdplatte @bbjubjub2494 thank you both for using and reporting issues re table tests! both logs and coverage should be fixed with #11575