Integration tests for tx, copy and bytecode circuits

[adria0]

No description provided.

[pinkiebell]

Nice! I left a few comments 🙂

[pinkiebell]

@AronisAt79 Can we support running CI checks on forks if we for example request it via a comment -or- if we approve a PR?
Edit: Adding a label that will run the ci tests on forks would be nice :)

I'm also wondering if it makes sense to prefix all heavy tests with heavy, e.g heavy_foo_bar so that we have a easier time filtering that via cargo test heavy across all crates?

[pinkiebell]

@adria0 Can you prefix the prover tests with serial_? Seems like we use that term already. In a future PR we can get rid of the crate exclusion stuff inside the CI runner :)

[AronisAt79]

I'm also wondering if it makes sense to prefix all heavy tests with heavy, e.g heavy_foo_bar so that we have a easier time filtering that via cargo test heavy across all crates?

Maybe @adria0 could better comment on that as i know he had a while back started an effort to create test batches according to duration and resource requirements. I agree that would be extremely helpful!

[pinkiebell]

My intention is to get the integration tests inside the CI runner and to have a easy filter locally without excluding crates. Because right now we miss important stuff inside the CI checks. I saw that we already use serial_, for every test function that uses the MockProver should be prefixed w/ serial_, this makes also possible to test things locally without grep'ing through :)

[AronisAt79]

@AronisAt79 Can we support running CI checks on forks if we for example request it via a comment -or- if we approve a PR? Edit: Adding a label that will run the ci tests on forks would be nice :)

@pinkiebell, i think it is doable - with some ( a lot ?) administration. But what would that offer against running CI on the fork independently? For PRs, if not done already, we can simply activate the workflows we want, based on event (pull request/push etc).

[pinkiebell]

@AronisAt79 Can we support running CI checks on forks if we for example request it via a comment -or- if we approve a PR? Edit: Adding a label that will run the ci tests on forks would be nice :)

@pinkiebell, i think it is doable - with some ( a lot ?) administration. But what would that offer against running CI on the fork independently? For PRs, if not done already, we can simply activate the workflows we want, based on event (pull request/push etc).

Somehow I misinterpreted that this wasn't a fork 😂 . Anyway, running the tests on our own runner - on PRs from forks - would be nice. And I think adding a label from the reviewer team is good enough authorization?

[adria0]

@adria0 Can you prefix the prover tests with serial_? Seems like we use that term already. In a future PR we can get rid of the crate exclusion stuff inside the CI runner :)

sure. done in c99ea9b

[pinkiebell]

🤩

[ChihChengLiang]

LGTM

[CPerezz]

Let's try to merge this so that when @adria0 is back this is not super far away from main and requires a lot of work to rebase.

[CPerezz]

LGTM for now to merge and prevent PR outdating.

I'd really consider to use testing setup/teardown to reduce the verbosity and redundancy in the tests.

Also, I think it would be benefitial to setup a final solution that unifies ALL the randomness used across all the tests so that we don't do different things on each PR/test.

See: #641

[CPerezz]

Instead of doing this on each test, why don't we use a crate like: https://github.com/markhildreth/test-context to do test setup/teardown?