Add real tests

[Divide-By-0]

Let's rename the circuit tests to contract tests since that what they currently are.

unit tests only have this right now:

PASS tests/e2e-ui.test.ts (11.786 s)
  App.js
    ✓ should allow email and eth addr to be entered into inputs (1217 ms)
    ✓ should start with an enabled prove button and status should be 'not-started' (1217 ms)

These only test trivial UI functionality; they don't actually verify the download functionality or witness generation works -- can we add tests for those? We should also use circom-tester to verify witness generation passes for the sample eml.

[isidroamv]

@Divide-By-0 I see that there are some working tests for the download functionality here but they take around 4-6 minutes to complete. Also, Can I know more details about the witness generation flow?

[Divide-By-0]

Hey, yeah it's a big download, GitHub actions is free for OSS though so should not be a problem. You can learn about witness generation in the circom2 docs and the snarkjs readme. You'll have to add a ts function for just witness generation.

[saleel]

Adding some context/update here

We have:

• Unit tests for circuit - we compile circuit, and test witness generation using a sample email
• Unit tests for contracts - we build circuit, and run tests against the committed (not "freshly" generated) verifier contract.
• Units/integration tests for UI app - part of GH actions after Add download test #11 - we are downloading zkey from the cloud URL and testing proof generation using sample email - not freshly built zkey / does not mint the NFT

What we can add:

• E2E tests for circuits + contracts + app - Generate new zkey and solidity verifier, serve the artifacts using a http-server, deploy the contracts to hardhat network, run the app e2e test against freshly generated artifacts and deployed contract (generate proof and mint the Twitter NFT - all locally using builds from the latest code).
• Trigger the above when there is a change in zk-email-verify/contracts repo - this might be possible directly if we point the dependency to Github repo instead of npm package (we would need to find a way to trigger action here based on update in that repo).