[Feature] contract mocking

[MarvinJanssen]

Many projects use external / 3rd party contracts. Fetching them from mainnet or testnet is not always ideal, nor would you want code that is not part of your project in your code base. Furthermore, sometimes you want to be able to exactly control outputs. I think Clarinet should have the ability to mock contracts.

This can take the form of an extension with a pure TS implementation, so only people that need it can bring it in.

Only minimal changes to Clarinet itself are required (of which preSetup was the first.) It mainly has to do with analysis. We would also have to think about how to deal with mocks when invoking clarinet console.

Here is an early implementation:
https://github.com/MarvinJanssen/clarinet/tree/feat/mock-contracts

Sample of how it could work:
https://github.com/MarvinJanssen/clarinet/tree/feat/mock-contracts/examples/mocking

However, one normally wants to be able to mock contract per unit test.

[LNow]

I'm not convinced in 100% if we need a separate TS API for creating mocks.
For test purposes we can create various types of test doubles without any extra API.

Example:

Clarinet.test({
  name: "returns the ticket price",
  preSetup(): Tx[] {
    let mockOracleCode = `
        (define-public (price (arg1 (string-ascii 24)) (arg2 (string-ascii 24)) (arg3 uint))
            (ok u2000000)
        )
    `;
    return [
      Tx.deployContract(
        "imaginary-oracle-v1",
        mockOracleCode,
        "SP000000000000000000002Q6VF78"
      ),
    ];
  },
  async fn(chain: Chain, accounts: Map<string, Account>) {
    let deployer = accounts.get("deployer")!;

    let wallet_1 = accounts.get("wallet_1")!;
    let block = chain.mineBlock([
      Tx.contractCall(
        `SP000000000000000000002Q6VF78.imaginary-oracle-v1`,
        "price",
        [types.ascii("usd"), types.ascii("stx"), types.uint(5)],
        wallet_1.address
      ),
    ]);
    console.table(block.receipts[0]);
  },
});

[MarvinJanssen]

Sure, we can do that, just like we can also construct transactions manually. A library simply makes it easier. It definitely does not have to (should not?) be part of the built-in clarity/index.ts file.

Furthermore, I do not like the idea of mixing languages so I rather not write Clarity snippets in TS files unless I absolutely have to. Having an exposed API gives us more type safety.

With the new Clarinet features coming out, we might want to explore different approaches as well.

[obycode]

Are the needs in this issue handled by #333?

[moodmosaic]

Are the needs in this issue handled by #333?

Partially, or perhaps implicitly.

• With feat: Introducing deployment plans #333 instead of preSetup you'd include the contract-call transactions at deployment time, for all tests.
• With the idea proposed by @MarvinJanssen you'd (explicitly) setup Mocks and Stubs, similar to @LNow's approach, for each test.

(If we move forward with this, the correct terminology matters, as in this snippet the Test Double is actually a Stub, not a Mock.)

[lgalabru]

I think these needs are handled in #333, although a better developer experience would be implemented with #357.

[lgalabru]

All the primitives are implemented and available to write such a library, I'll close this issue!