disintar/toncli

Improve func tests

tvorogme opened this issue · 4 comments

tvorogme commented
Improve func tests
bminaiev commented

List of things we don't like and (ideally) want to fix:

  1. Currently developers need to manually specify method_id for each test following some rules (they should start from 0, corresponding "check" function needs to have method_id equal to "prepare" function method_id + 1). We want to fully remove the necessity of manual method_ids.
  2. Developers need to manually find function selectors of smart contract's tested methods. Ideally we want to just specify names of tested functions instead of their ids.
  3. Currently each test runs only one smart contract function. Would be great to be able to run several (possibly different) functions inside one test. Persistent data (c4) during each function call should be equal to what was saved during the previous call. Ideally we want to "dynamically" generate a list of functions to be called (e.g. via loops). But even if we require a number of function calls known at compile time, it will already be a huge improvement.
  4. Improve stack corruption error reporting. Currently if tests or smart contract functions do not behave nicely with stack (e.g. consume or add more/less entries from stack), some strange situations could happen, which is hard to debug.
  5. Something else?
bminaiev commented

Some ideas (they are all theoretical, and potentially could not work) about how to improve things.

  1. We need to know which functions are tests, and need to be run. Currently this is done by using specific method_ids. We can use different conventions, and use function names instead. Say, if the function name starts with "__test", we consider it as a test, and will run it. There is also a question about how to find the corresponding "checker" function. We can return a reference to the checker function (e.g. as continuation) together with other test parameters (stack, data, c7, ...) from the test function.
  2. As in the previous point, we can just return the tested function as continuation, not a function selector. This will require a compiling test together with the contract's code. It could lead to some problems (e.g. developers will not be able to use the same function names and global variables inside test and contracts code). But also it makes it possible to run some helper contracts functions inside tests.
  3. This part is the most questionable. We can generate a list of functions to be called (together with corresponding stack, c7, checker functions ...) from each test, and then run each function separately (providing c4 from previous call). We need to think about how to return this list from the test function. Also this way all function calls should be known in advance, which means they can't depend on responses from smart contracts.