chore: low-hanging deviations in integ tests

[jcsec-security]

What ❔

Part of the hardening efforts to adhere to the new testing guidelines. Limited to our current integration tests.

• Empty vm.expectRevert() instaces.
• Missing validation of emitted events.
• Use assert* statements instead of require for outcome validation for consistency.
• L2GatewayTestAbstract.t.sol 139-140 did not validate anything in reality, as the values of those variables were manually set in ln 117 and SharedL2ContractDeployer.sol:101
• Tagged unjustified commented code

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.

[jcsec-security]

Open question:

• In the ChainRegistrationSender contract (here) the registerChain() function does not emit any event although it modifies its storage. Is there a reason for this?

[StanislavBreadless]

maybe makes sense to make a dedicated constants for 0xdead?

[jcsec-security]

We can just add address constant RAND_ADDRESS = address(0xDEAD); to a new TestConstants.sol, for example at l1-contracts/test/foundry . We can also use foundry labeling through address randomAddress = makeAddr("randomAddress");, it gives clearer traces but we will have to sprinkle it around the test-suite.

[StanislavBreadless]

can we use standard foundry assertions for events?
if not, is it possible to make a standalone function for checking these events? So that it could reused in the future

[jcsec-security]

I think not, as these events are not emitted by the fn being called, but by subsequent calls along the line, that is why I was using vm.getRecordedLogs and then iterating over the contents.

I added a library in l1-contracts/test/foundry/l1/integration/utils/, please check and let me know.