This is still WIP
@anishnaik Looking for early feedback. I settled on ContractBytecodes or CompiledContracts to avoid adding the logic for opening the file + looking for the bytecode in the handler (but still be able to connect compiled contract with the tracer). Using CompiledContracts will provide contract context access for future cheatcode implementations but I don't know if it's truly needed at this time. I additionally tried the following strategies but didn't get successful results:

• Added Fuzzer field to TestChain struct:
  • Set the reference when creating the chain
  • Access Fuzzer's contract definitions through this reference
  • Issue: Creates import cycle between packages (test_chain.go <-> fuzzer.go)
• Use fuzzer context passed to TestChain
  • Store and retrieve Fuzzer through context
  • Issue: probably not best use of the context

On a separate note, fuzzing.fuzzer_test.TestCheatCodes fails on the master branch on my machine

Hey @0xZRA sorry for the delay - will provide feedback today :)

@0xZRA before reviewing the PR i want to make sure we satisfy the issue. It is possible that the creator of the issue does in fact want the versioning support as well. If they do then you may need to add support for that as well.

@0xZRA before reviewing the PR i want to make sure we satisfy the issue. It is possible that the creator of the issue does in fact want the versioning support as well. If they do then you may need to add support for that as well.

@anishnaik For sure, makes sense to me

No major feedback outside of the optimization I mentioned :) Appreciate all the work!

I should be able to wrap this up within next few days

@anishnaik I'm concerned that without being able to run the tests locally, there's no way for me to confirm if the proposed code is functioning correctly. Other than that, the changes are ready for your review

Hey @0xZRA I'm going to push the patch for the bug in the master branch right now. Then you will be able to pull it down and make sure all the tests pass locally. Btw you should still be able to specifically test your unit test instead of running the whole test suite. That should help you validate the expected behavior.

Btw I know why your test is failing - your test contract's name has to be TestContract.

Btw I know why your test is failing - your test contract's name has to be TestContract.

Thank you, it worked!

@0xZRA can you fix the compilation issues in the test?