Implement "acceptance" type testing

[derekpierre]

An example that illuminates the limitations of our current tests that only do mocking - #263 (comment).

• Identify smart contract mocks in taco-web
• Asses the impact of using a local blockchain instead of mocks

[KPrasch]

Currently, taco-web only handles read-only blockchain operations, and our mocks do a pretty good job at mimicking those. Additionally, any major breaking changes often show up first in our CI checks with nucypher-core or nucypher-contracts, which helps us catch issues early. Since there aren't many of these on-chain reads being mocked, it’s reasonable to expect that any developers working on this will follow up with the appropriate issues in taco-web as needed. It keeps our approach manageable and focused.

You can peek at our current mock setup here: taco-web test utilities.

On expanding taco-web to include write operations or mutable states (think DKG initialization) - it’s a valid point, and it makes a stronger case for more robust testing like E2E. But for now, setting up live smart contracts for testing feels excessive, and that’s why we’ll likely close this issue as "wontfix." The setup just isn’t justified at the moment considering the overhead of establishing new test infrastructure, synchronization with nucypher-contracts, populating mock contracts with data, etc.

I'm definitely not against E2E tests. In fact, if we start gearing up for bigger test scenarios, it’d be wise to hash out what specific E2E tests we might need. Let’s open some targeted issues for those discussions.

If there are any additional suggestions for an alternative interpretation of what "acceptance" testing represents feel free to comment here, but my general assessment is that it's best to close this issue as "wontfix", and open more tightly scoped test scenarios as needed in the future.