Run challenge test against downloaded contract

[MattPereira]

Overview

We need to figure out how to run the challenge tests against the contract we are fetching from Etherscan during challenge submission.

The foundry tests for challenges may need to be modified in order for it to be possible to import the downloaded contract. The test is currently passing because downloaded repo contains passing contract code, but we need to figure out how to make the test run against the downloaded contract instead of the default contract.

Here is snippet of viable solution used for speedrun ethereum that was built with hardhat

[escottalexander]

It seems to me that there are three options:

1. editing the foundry test import to use the download-${contractAddress} name
2. instead of using a special name for the contract we could use the name that is defined in the test contract. For example, instead of the contract being called download-${contractAddress} it would just be called YourCollectible.
3. Lastly, similar to the first solution but maybe a little cleaner since we won't be editing lines in a file, we write a new file that imports the contract with the download-${...} naming and called it Imports.sol and we pull all imports from that file in the test. This way the test is unmodified and Imports.sol can be deleted along with the contract each run.

I like the last solution better than the first but I feel like the easiest solution is just to use the correct name for the test from the start. Any reason why we can't do this? If we were saving the files for later diagnosing why it didn't work and such then it would make sense for the file to be marked by the exact contractAddress but otherwise I don't see a need.

[MattPereira]

Is option 1 suggesting we reach into the test import for the corresponding submitted challenge programatically to change the import statement before running the test?

For option 2 we could ammend install script to yeet any file inside foundry/contracts which would free up the namespace, but I wonder if multiple submissions happening close together would cause some sort of autorenaming like WrappedETH copy.sol when the script tries to write the same file name twice

For option 3 I only partially follow. How would the unmodified test have access to the download-<contract_address>.sol? Or like how would it point at it from within the test without knowing the filename ahead of time?

Might make sense to hop on a call sometime to discuss this one.

[escottalexander]

@MattPereira Reach out on TG to set up a time to discuss this.

[escottalexander]

@MattPereira Just wanted you to see how we ended up going about this. https://github.com/BuidlGuidl/eth-tech-tree-challenges/pull/61 Basically we can use

CONTRACT_PATH="download-0x12345..." yarn foundry:test

To target a specific contract each time we run the command.