PRT contracts unit tests

[stephenctw]

• LeafTournament.sol is at 74% coverage, mostly because the solidity-step codes are not included in the scope.
• 100% coverage for all other contracts.
• Currently there are three kinds of commitments being tested
  • all leafs are 0
  • all leafs are 1
  • all leafs are 0 except the last leaf is 1
  • this covers the cases where
    • divergence happens at very first node (go down the tree to left always)
    • divergence happens at very last node (go down the tree to right always)
    • we could probably create more complex cases for later improvements.
• (Optional) Run ./coverage.sh from prt/contracts folder, and open report/index.html in a browser can give you a very clear visual presentation of the test coverage report.

[GCdePaula]

This is great :)

I've left a few comments. I'm ready to merge this, and if we feel the comments make sense, open a new PR.

There are a few granularities to testing, and I think we should test on all of them. On one end is more on the function level, and on the other end is testing the whole "executable". I think we should add more tests on the function level.

On this perspective, a few high level things we want to test, most of which I believe you're already testing:

• Matchmaking: We can use single level tournament for this. We test join, for 1 to 4 players (in all of these numbers, something interesting happens). We test advance (the most important thing here is to also test the invalid cases). We test timeout. We test win by step (we don't need to test meta-step here, only test that the consequences of a successful step are what we want).
• Match: For height zero, match for height one, match for height two. Here we should get to full coverage of all edge cases. As such, we won't need to test the details of a match anywhere else, we can assume it's working.
• Meta-step: We don't have to instantiate and advance a whole dispute to the point of meta-step to test meta-step; we can test this function as a unit (feel free to move it to a library if you feel it helps!). Here we should test all corner cases of meta-step.
• Multi-level: I guess this is the larger integration test. The main thing we haven't covered with the previous tests is on the "switch" between levels (both going down and going up). I think we need to also devise a clock test on this switch. We can assume what we tested before like the meta-step function works (we should make sure a match reaches the point of meta-step and calls it, but we don't need to test all the edge cases of meta-step here). Likewise, we can consider commitments with the minimum height, since we've already tested a match with varying heights.
• Parallel inner tournaments: Integration test with 3 players. Integration test with 4 players (means that there would be two inner tournaments concurrently).

[GCdePaula]

I think we should also test advanceMatch here. Like, I think this file alone should get to 100% coverage on Match.sol.

Now that we can easily set the tree/commitment height, it should be a lot easier.

[GCdePaula]

This is great! A few comments.

It's possible to test all the meta-step cases (compute step, rollup step, compute reset, rollup reset, gio) as units. Like, we don't have to create a top, middle, and bottom, doing bisections and sealing, just to get to meta-step. I believe we can also just directly test the meta-step function. Sometimes it's better to test a single thing at a time.

It's possible to create a BottomTournament without the top and middle. Just remember that it won't point to a valid "parent", but that's ok depending on the test.

As a sort of integration test, I love how it's possible to test a whole "refutation" (top to bottom) in a single function in a clear way. I think it might also be a good test to "finish" the tournament. Like, you managed to reach the bottom tournament and win the match --- is it possible to now "bubble up", reach the top tournament, vm.roll and win the dispute?

[GCdePaula]

Also, one case that's interesting to test is timeout. We should test what happens when we timeout on the top, then test bisect on top until middle and timeout on middle, and finally test bisect on top+middle and timeout on bottom.

(Not here on this file though, I think.)

[GCdePaula]

I think the clock is the most delicate part of our code. I'll look more closely later, but it looks great :)