How to Run Tests About Tezos?

how to run tests about tezos

Depending on what you want to test, there are several options.

1. use the tezos octez sandbox as provided by pytezos, there are two options:
   • SandboxedNodeTestCase: needs the user to trigger the baking operation,
   • SandboxedNodeAutoBakeTestCase: same, but with the baking operation automatically run,
2. use flextesa,

Let’s try to make a soft multi criteria decision analysis.

I can guess the following objectives to fill when running tests in tezos.

1. fine control over the sandbox lifecycle, like when blocks are backed,
2. independent node that simulates the common usage,
3. easy to start and stop,
4. easy to forge/sign/inject a single operation,
5. able to have as many accounts as needed at bootstrap,

This is how I would position the three propositions :

Use the letters s, a f to respectively refer to SandboxedNodeTestCase, SandboxedNodeAutoBakeTestCase and flextesa.

   worst                                                                         best
1.                             f                           a            s
2.                  s                             a                        f
3.                            a                                          f    s
4.                             s                                             af
5.                                 s         a                            f

This is the rationale

1. • this is the initial intent of s,
   • f does not provide any control over the baking, but some control over the time of the blocks,
   • a is somehow between both then
2. • this is the intent of f,
   • you can do stuff with s, but you have to manually bake,
3. • f only needs a simple docker run command,
   • s is even better, you simply use the class and don’t mind about dealing with docker
   • a is hard to stop, as it appears to make the program hang (at the time of writing this [2022-08-09 Tue])
4. • with f or a, you do what you would normally do with any other node
   • s needs you to manually bake. That means that a workflow with forge().sign().inject().wait() is not possible as you have to manually insert a bake() command. It would then be forge().sign().inject().bake().retrieve()¹
5. tezos sandbox bootstrap accounts
   • with f, it is as simply as providing the names at startup
   • with a or s, because they are based of the sandbox of octez, you only have access to the 6 hardcoded accounts²

It’s quite easy to see that no solution is pareto dominated according to all those objectives. They all are part of the pareto front.

Of course, depending on you use case, there might be.

For example, in a test where speed is key and you don’t mind putting some extra code to control the baking, you would only look at 1 and s is the obvious choice.

In the case that you want to simulate some real case scenario with a lot of accounts, the needed dimensions are 2 and 5 and f is the obvious choice.

In other situation, you will need to decide a compromise and decide what dimensions weights the more.

Permalink