ability to start a contract without a bundle #10558
Comments
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
|
I'm confused.
To clarify, is code coverage wanted for unit tests, or for more complex tests like "bootstrap" tests?
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". |
|
endojs/endo#2735 looks like it could make this feasible cc @kriskowal |
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
startInstancewith 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
The text was updated successfully, but these errors were encountered: