feat(tests): eof section order tests

[winsvega]

🗒️ Description

Construct eof container with skipped sections combinations

Example:

• take code section, make it appear only in container header and header types, but skip printing bytes in the body
• take code section, make it appear only in container body but skip printing bytes in the header
• take code section but print it in a wrong order in header or body

🔗 Related Issues

#550

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[marioevz]

Some comments, thanks!

[marioevz]

Another comment is that, since there are some repeated cases with the current parametrization approach, and we are actually listing each case in get_expected_code_exception anyway, I think we could change the parametrization to:

@pytest.mark.parametrize("section_kind,section_test,test_position,expected_bytecode,expected_exception",
    [
        pytest.param(
            SectionKind.TYPE,
            SectionTest.MISSING,
            CasePosition.HEADER,
            "ef000102000100030400010000800001305000ef",
            EOFException.MISSING_TYPE_HEADER,
        ),

[winsvega]

Another comment is that, since there are some repeated cases with the current parametrization approach, and we are actually listing each case in get_expected_code_exception anyway, I think we could change the parametrization to:

@pytest.mark.parametrize("section_kind,section_test,test_position,expected_bytecode,expected_exception",
    [
        pytest.param(
            SectionKind.TYPE,
            SectionTest.MISSING,
            CasePosition.HEADER,
            "ef000102000100030400010000800001305000ef",
            EOFException.MISSING_TYPE_HEADER,
        ),

hm I was thinking what if we are to add more combinations.
the current way it will be clear what are the new combinations would be. (like if I add subcontainer)
the code verification is becauses eof is in development I don't feel safe without it. (thus python falls back to json tests)

[marioevz]

Another comment is that, since there are some repeated cases with the current parametrization approach, and we are actually listing each case in get_expected_code_exception anyway, I think we could change the parametrization to:

@pytest.mark.parametrize("section_kind,section_test,test_position,expected_bytecode,expected_exception",
    [
        pytest.param(
            SectionKind.TYPE,
            SectionTest.MISSING,
            CasePosition.HEADER,
            "ef000102000100030400010000800001305000ef",
            EOFException.MISSING_TYPE_HEADER,
        ),

hm I was thinking what if we are to add more combinations. the current way it will be clear what are the new combinations would be. (like if I add subcontainer) the code verification is becauses eof is in development I don't feel safe without it. (thus python falls back to json tests)

Code verification is totally fine, I like that we are not blindly trusting our EOF bytecode constructor.

What I like about this second approach is that it's easier to read for someone that comes into the file and does not have that much knowledge about how parametrization combinations work, even if we add more cases, I think it's a bit better to be explicit IMO.

[winsvega]

Another comment is that, since there are some repeated cases with the current parametrization approach, and we are actually listing each case in get_expected_code_exception anyway, I think we could change the parametrization to:

@pytest.mark.parametrize("section_kind,section_test,test_position,expected_bytecode,expected_exception",
    [
        pytest.param(
            SectionKind.TYPE,
            SectionTest.MISSING,
            CasePosition.HEADER,
            "ef000102000100030400010000800001305000ef",
            EOFException.MISSING_TYPE_HEADER,
        ),

hm I was thinking what if we are to add more combinations. the current way it will be clear what are the new combinations would be. (like if I add subcontainer) the code verification is becauses eof is in development I don't feel safe without it. (thus python falls back to json tests)

Code verification is totally fine, I like that we are not blindly trusting our EOF bytecode constructor.

What I like about this second approach is that it's easier to read for someone that comes into the file and does not have that much knowledge about how parametrization combinations work, even if we add more cases, I think it's a bit better to be explicit IMO.

what happend. now you prove me that the way json fillers expect sections were organized is better, and I prove you that python scripting is superior )

[marioevz]

Another comment is that, since there are some repeated cases with the current parametrization approach, and we are actually listing each case in get_expected_code_exception anyway, I think we could change the parametrization to:

@pytest.mark.parametrize("section_kind,section_test,test_position,expected_bytecode,expected_exception",
    [
        pytest.param(
            SectionKind.TYPE,
            SectionTest.MISSING,
            CasePosition.HEADER,
            "ef000102000100030400010000800001305000ef",
            EOFException.MISSING_TYPE_HEADER,
        ),

hm I was thinking what if we are to add more combinations. the current way it will be clear what are the new combinations would be. (like if I add subcontainer) the code verification is becauses eof is in development I don't feel safe without it. (thus python falls back to json tests)

Code verification is totally fine, I like that we are not blindly trusting our EOF bytecode constructor.
What I like about this second approach is that it's easier to read for someone that comes into the file and does not have that much knowledge about how parametrization combinations work, even if we add more cases, I think it's a bit better to be explicit IMO.

what happend. now you prove me that the way json fillers expect sections were organized is better, and I prove you that python scripting is superior )

Lol, I guess I just felt it was confusing in this context, because we still need a switch-case implemented to make it work.

I think having combinations handled by parametrize is still possible, it's just that we need to figure out the logic to fill the exceptions maybe?

[marioevz]

Thanks!