Solidity
A test proves your contract keeps its promise after each change. For this track, your repo must show that the contract builds and the important actions are checked locally before testnet deployment.
Hardhat 3 is a current mainstream Solidity toolkit. It supports Solidity tests, TypeScript tests, and fuzzing.
A default Hardhat 3 project gives you the folders recruiters expect to see: contracts, test, scripts, ignition/modules, and hardhat.config.ts.
0 of 8 lessons done · proved by a submitted project with a public repository
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
npx hardhat --init
# or, if you use pnpm
pnpm dlx hardhat --init
# or, if you use yarn
yarn dlx hardhat --initDo not test only that the contract deploys. Test the rules a user can break.
For a college project, cover the happy path, at least one rejected action, and one edge case. If your contract has an owner-only function, test that a non-owner cannot call it.
Write the plan before asking AI to generate test code. This keeps the AI from testing random things that look correct but miss your actual rules.
Contract: EventPass
Rules to test:
1. The deployer becomes the organizer.
2. A student can register with a name and college.
3. The same wallet cannot register twice.
4. Only the organizer can close registrations.
5. Registration fails after registrations are closed.
6. The contract emits an event when a student registers.You can ask ChatGPT, Gemini, or Claude to draft Hardhat tests from your contract. Paste the contract and your test plan, then ask for tests that match your project type.
Check the output. It should import from your actual files, use the function names in your contract, and assert failures for restricted actions. Delete tests for features your contract does not have.
Prompt:
I have this Solidity 0.8.x contract. Write Hardhat 3 tests for the rules below.
Use the existing folder structure: contracts/ and test/.
Do not invent functions.
Include tests for success cases and expected reverts.
Rules:
[paste your test plan]
Contract:
[paste your contract]Beginners often write tests that only call functions without checking the result. That does not prove much.
Every test should end by checking state, an event, a returned value, or a revert. Also take compiler warnings seriously. A repo with warnings looks unfinished.
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Answer the quick check to finish this lesson.