github.com/cgcardona/r-subnet-evm@v0.1.5/contracts/test/README.md (about)

     1  # Testing Precompiles
     2  
     3  If you can, put all of your test logic into DS-test tests. Prefix test functions with `step_`. There's also a `setUp` function that gets called before the test contract is deployed. The current best-practice is to re-deploy one test contract per `test` function called in `*.ts` test definitions. The `setUp` method should be called once, then `step_` functions passed in as the 2nd argument to `test("<description>", <step_function_name_OR_array_of_step_function_names>)` will be called in order. `test.only` and `test.skip` behave the same way as `it.only` and `it.skip`. There's also a `test.debug` that combines `test.only` with some extra event logging (you can use `emit log_string` to help debug Solidity test code).
     4  
     5  The `test` function is a wrapper around Mocha's `it` function. It provides a normalized framework for running the
     6  majority of your test assertions inside of a smart-contract, using `DS-Test`.
     7  The API can be used as follows (all of the examples are equivalent):
     8  
     9  ```ts
    10  test("<test_name>", "<contract_function_name>");
    11  
    12  test("<test_name>", ["<contract_function_name>"]);
    13  
    14  test("<test_name>", {
    15    method: "<contract_function_name>",
    16    overrides: {},
    17    shouldFail: false,
    18    debug: false,
    19  });
    20  
    21  test("<test_name>", [
    22    {
    23      method: "<contract_function_name>",
    24      overrides: {},
    25      shouldFail: false,
    26      debug: false,
    27    },
    28  ]);
    29  
    30  test(
    31    "<test_name>",
    32    [{ method: "<contract_function_name>", shouldFail: false, debug: false }],
    33    {}
    34  );
    35  ```
    36  
    37  Many contract functions can be called as a part of the same test:
    38  
    39  ```ts
    40  test("<test_name>", ["<step_fn1>", "<step_fn2>", "<step_fn3>"])
    41  ```
    42  
    43  Individual test functions can describe their own overrides with the `overrides` property.
    44  If an object is passed in as the third argument to `test`, it will be used as the default overrides for all test
    45  functions.
    46  The following are equivalent:
    47  
    48  ```ts
    49  test("<test_name>", [
    50    { method: "<contract_function_name>", overrides: { from: "0x123" } },
    51  ]);
    52  
    53  test("<test_name>", [{ method: "<contract_function_name>" }], {
    54    from: "0x123",
    55  });
    56  ```
    57  
    58  In the above cases, the `from` override must be a signer.
    59  The `shouldFail` property can be used to indicate that the test function should fail. This should be used sparingly
    60  as it is not possible to match on the failure reason.
    61  Furthermore, the `debug` property can be used to print any thrown errors when attempting to
    62  send a transaction or while waiting for the transaction to be confirmed (the transaction is the smart contract call).
    63  `debug` will also cause any parseable event logs to be printed that start with the `log_` prefix.
    64  `DSTest` contracts have several options for emitting `log_` events.