feat: assert.CheckFunction

[ivokub]

Description

Change cherry-picked from #1407. I'm still not sure about the method signature - I think if we have assert.CheckCircuit, then it would be natural to have assert.CheckFunction if we want to test only a single method. Definitely something different than having package-level Function.

Secondly, I think it should behave similarly as CheckCircuit, so instead of hardcoding SolverSucceeded, it should detect what build tags are provided and then either run in test engine/solver/prover/solidity to have full coverage.

And I'll also try to see if we can get away with the global map of the functions being tested. Feels too hacky for me, I hope there is some other solution.

WIP!

Fixes # (issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How has this been tested?

• Test A
• Test B

How has this been benchmarked?

• Benchmark A, on Macbook pro M1, 32GB RAM
• Benchmark B, on x86 Intel xxx, 16GB RAM

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Tabaie]

so instead of hardcoding SolverSucceeded

I think it is reasonable to always expect success. A single function is simpler than a whole circuit in that rather than succeeding or failing, it is just expected to map a particular input to a particular output. So its failure to provide output y is the same as its success at providing output y' != y

[ivokub]

so instead of hardcoding SolverSucceeded

I think it is reasonable to always expect success. A single function is simpler than a whole circuit in that rather than succeeding or failing, it is just expected to map a particular input to a particular output. So its failure to provide output y is the same as its success at providing output y' != y

I didn't mean that we should be able to test invalid inputs also. It was rather that assert.CheckCircuit does several things based on build tags:

• runs only on test engine
• previous + runs the solver
• previous + performs key setup and runs prover/verifier
• previous + proves with Solidity compatible hash fn and runs Solidity verifier + serialization tests

Imo if we implement a generic utility, then it should behave similarly.

[Tabaie]

Ah I see. Yes agreed that that's desirable.