This step-by-step guide will help you use developmental test code to validate smart contract exploits

Using the project’s code base and test frameworks for trying exploits, written as unit tests.

This method has a few advantages:

• Sometimes contracts are deployed, but there isn’t solid info on finding them. Using the development team’s code base makes things easier because you don’t have to interact with deployed contracts.
• You can easily test contracts that are in scope for the bounties but haven’t been deployed yet. Forking the mainnet wouldn’t help you here.
• Sometimes project code bases already have tons of tests and scenarios ready. You just need to tweak a few lines of a unit test to test an exploit.
• Project development teams are familiar with their unit tests. A new unit test using the same practices is easier for them to validate than a stand-alone PoC (proof of concept).

Being able to quickly modify an existing test and check if an exploit works is a valuable asset to have in your toolkit.