Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ability to start a contract without a bundle #10558

Open
turadg opened this issue Nov 22, 2024 · 1 comment
Open

ability to start a contract without a bundle #10558

turadg opened this issue Nov 22, 2024 · 1 comment
Labels

Comments

@turadg
Copy link
Member

turadg commented Nov 22, 2024

What is the Problem Being Solved?

The main problem is that we want to have code coverage reports on contracts. Zoe can only start a contract from an Installation of a bundle. Currently the Endo bundler is incompatible with code coverage tooling (#1817).

A secondary problem is that unit tests of contracts have to bundle just to be able to run the code that's right there on disk.

Description of the Design

What could solve both these problems is some way to startInstance with some sort of Installation that represents a set of files on disk. (either by being some new kind of installation that's used just for testing, or some new kind of bundle that virtualizes a set of local files).

This would in turn cause Zoe to load the JS code directly from disk, and hopefully then be visible to C8.

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

mergify bot added a commit that referenced this issue Dec 3, 2024
closes: #10388
refs: #10511

## Description

Prune `testBorrow`, `testRepay` methods along with contract tests that depend on them.

 - Several tests are largely covered by share-pool-math tests
   - 1 was not, so I made a pool-share-math test to cover _repay succeeds with no Pool or Contract Fee_.
 - Several tests basically checked the interface guards of `lp.borrower.borrow` / `lp.repayer.repay`.
    These are internal APIs with static types.
   - testing consistency between interface guards and static types
     might have some value, but, I suggest, not enough for the cost

### Scaling / Documentation / Upgrade Considerations

none

### Security / Testing Considerations

small loss in test coverage - mostly in test redundancy

`makeTestPushInvitation` remains on the public facet. Getting rid of it in due course remains critical.
I expect / hope we can get rid of it in #10606 (cc @samsiegart ) .

Ideally, the liquidity-pool exo would have unit test coverage. I looked into that but found that I would have to build substantial ZCF / Zoe test tooling. Since `liquidity-pool.js` is just 360 lines of straightforward Zoe API usage, I suggest we postpone that under...

 - #10558
@mhofman
Copy link
Member

mhofman commented Feb 12, 2025

I'm confused.

The main problem is that we want to have code coverage reports on contracts.

To clarify, is code coverage wanted for unit tests, or for more complex tests like "bootstrap" tests?

A secondary problem is that unit tests of contracts have to bundle just to be able to run the code that's right there on disk.

to startInstance with some sort of Installation that represents a set of files on disk.

Why do unit tests of a contract involve Zoe (at least the real thing)? Why can't they run in a "ZCF environment" that just exercises the contract's entrypoint directly?

Sure the fidelity is a little lower, and it assumes the contract doesn't keep global state, but I think it would make the unit test more "unitary".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants