.foundryignore

[sakulstra]

Hello,
in various projects i came now to the point where i got an ever increasing amount of tests, for things that are no longer relevant (e.g. because it was testing sth before execution at a certain block, but is now executed).

Now being in git obviously one could "remove" the test and find it in git history if ever needed.
While that works, it's a bit sad as tests can suite as a good documentation and reference for further code.

Therefore I'm wondering if it would be reasonable to follow the likes of .*ignore glob matchers to permanently ignore files from build/test/etc.
I saw on the docs that for e.g. tests there is the option to --match-contract etc. to include or exclude but usage is cumbersome when i know TestX is Test i want to never run again so i could just run forge test to run everything not currently ignored.

[mds1]

Would a vm.skipTest(bool) cheat work to conditionally skip if some condition is met? ref #1123

[sakulstra]

I think no, in the end it's a slightly different usecase.

In #1123 you want to conditionally skip tests, what I want to do is unconditionally ignore whole contracts.
While with #1123 this would be archivable by altering all tests and adding a vm.skipTest that is more or less the opposite of what i want to do.

For me it would be good if contracts, could:

1. stay unchanged (for historical reasons)
2. be ran manually when ppl explicitly via --match-contract
3. be ignored by default when running forge test

Similar to how i might want to .prettierignore a folder to exclude it from automatic linting when linting via glob ./**, but still have the possibility to explicitly lint a file in that folder.

Ideally this would be archived via toml or .foundryignore

[mds1]

I see, makes sense. Do you mind opening an issue for this feature request?

Also wonder if @hexonaut has an approach they use cause I'd guess they're similar in only needing some tests until a certain point (but I could be wrong)

[hexonaut]

Maker is more modular so tests are usually focused enough to run them all.

[sakulstra]

ah this is not about aave-core actually (just do eliminate any misconception, we're at bgd not aave anyways).

As community contributors we have a repository where we test proposals and there tests get irrelevant every ~10 days 😅 - as the proposals have failed or been executed. It would not be a big problem(it currently isn't a problem) to run them all, but seems wasteful/unnecessary and not scale very well, which is why i raised this as a discussion.