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).

The test function is a wrapper around Mocha's it function. It provides a normalized framework for running the majority of your test assertions inside of a smart-contract, using DS-Test. The API can be used as follows (all of the examples are equivalent):

test("<test_name>", "<contract_function_name>");

test("<test_name>", ["<contract_function_name>"]);

test("<test_name>", {
  method: "<contract_function_name>",
  overrides: {},
  shouldFail: false,
  debug: false,
});

test("<test_name>", [
  {
    method: "<contract_function_name>",
    overrides: {},
    shouldFail: false,
    debug: false,
  },
]);

test(
  "<test_name>",
  [{ method: "<contract_function_name>", shouldFail: false, debug: false }],
  {}
);

Many contract functions can be called as a part of the same test:

test("<test_name>", ["<step_fn1>", "<step_fn2>", "<step_fn3>"])

Individual test functions can describe their own overrides with the overrides property. If an object is passed in as the third argument to test, it will be used as the default overrides for all test functions. The following are equivalent:

test("<test_name>", [
  { method: "<contract_function_name>", overrides: { from: "0x123" } },
]);

test("<test_name>", [{ method: "<contract_function_name>" }], {
  from: "0x123",
});

In the above cases, the from override must be a signer. The shouldFail property can be used to indicate that the test function should fail. This should be used sparingly as it is not possible to match on the failure reason. Furthermore, the debug property can be used to print any thrown errors when attempting to send a transaction or while waiting for the transaction to be confirmed (the transaction is the smart contract call). debug will also cause any parseable event logs to be printed that start with the log_ prefix. DSTest contracts have several options for emitting log_ events.