ForeignInvestments: Unitary tests & fuzzer

[lemunozm]

Description

Unitary tests for foreign investments

Changes and Descriptions

• Mock files
• UTs with mocks. It seems like this path is never-ending and collides with integration tests.
• UTs for states. It seems like this path is never-ending and very difficult to maintain if future changes are made.
• Fuzzer. Fix the above problem with programmatic testing in order to check all cases at once with fewer lines.

[lemunozm]

@wischli I've needed to tweak a bit the InvestStateConfig trait here: c12b203.

I missed the fact that auto implementations for any T do not allow creating a different implementation later for any other type, so we would still need Config in tests, and then we are not taking advantage of such a new trait. So, I've added a new type Of<T> (that emulates the jargon we use when a type uses T), that will be used only for production and implements InvestStateConfig instead of doing it for any T. That way, we can create other types with other implementations for testing.

Tell me WDYT and if you prefer this change in your PR

[wischli]

@wischli I've needed to tweak a bit the InvestStateConfig trait here: c12b203.

I missed the fact that auto implementations for any T do not allow creating a different implementation later for any other type, so we would still need Config in tests, and then we are not taking advantage of such a new trait. So, I've added a new type Of<T> (that emulates the jargon we use when a type uses T), that will be used only for production and implements InvestStateConfig instead of doing it for any T. That way, we can create other types with other implementations for testing.

Tell me WDYT and if you prefer this change in your PR

I suppose it will make maintaining sync between this PR and mine much easier for you? In that case, I would add to to mine as well. Otherwise, we can also leave it untouched in #1473.

[lemunozm]

If the intention is to merge your PR today, and no changes there are expected, we can leave it as it is. If you find that you need to make some "big" change, then I think we can put this change just before. By now, we can leave it here 👍🏻

[lemunozm]

Just as a thought (mostly to myself).

Given the number of state combinations we have, maybe the best way to test this is to extract the invariant laws of this (i.e. the amount of money in the system must remain the same, independently of how many swaps are done) and create a fuzzier ensuring the invariant is always fulfilled for all combinations.

[wischli]

Super clean and elegant code as always! Thanks for complementing the existing integration tests with valuable fuzz tests plus providing mock skeletons.

I have three super minor nits which can be ignored. We could merge this PR right now or wait until RedeemState fuzzing is implemented. Totally fine with doing this in a subsequent PR.

[lemunozm]

plus providing mock skeletons.

My first intention was to create individual tests using mocks, but I realized that testing for all transitions could take me months, because I need to evaluate each parameter of each mocked call, and most of what I would check is already covered by integration tests. Anyway, it still can be seen as a future work (or used by other pallets), that's why I leave the mock skeletons there.

[cdamian]

Awesome stuff @lemunozm!

[lemunozm]

Updated with last changes of #1556. Should be ready to be merged now

[wischli]

Re-approving!