Make prediction-markets easy to configure (or split it)

[maltekliemann]

Bit of a meta issue. When I want to test a pallet that depends on some small part of prediction-markets, I have two options:

• Implement a fake version of the parts of prediction-markets that I need.
• Add prediction-markets, court, authorized, global-disputes, simple-disputes, swaps and liquidity-mining to the mock. In the case of testing the new swaps pallet, I don't need any of these.

I'm not a huge fan of the first option as I like having integration tests for our pallets, but the second option really sucks.

[sea212]

Ideally we'd have those tests separated, as in prediction-markets unit tests (within the crate) mock the functionality of dependencies and can work solely by itself, thus effectively testing the unit itself. Integration tests on the other hand should reside in the runtime crate, where each specific dependency is known an accessible.

[Chralt98]

Ideally we'd have those tests separated, as in prediction-markets unit tests (within the crate) mock the functionality of dependencies and can work solely by itself, thus effectively testing the unit itself. Integration tests on the other hand should reside in the runtime crate, where each specific dependency is known an accessible.

This explains the basic ideal (as you said) for the difference of unit tests and integration tests. However, it does not solve the fundamental problem Malte mentioned. I fully understand Malte's concern and I agree, it's a mess to replicate all the dependencies of another dependency. This is why I am personally in favour of testing not against a mock, but against the actual runtime, or if we want to have a mock, then test against it, but with all dependencies that we have (a full runtime representation). This is kind of the idea of integration tests, but it also allows unit testing and it is closer to the actual production runtime behaviour. So this would get rid of all the mocks that we have and replace them with either the real runtime or a general mock close to runtime.

This comes with the implication that we would need to figure out how to run benchmark test, since those rely on a mock inside each pallet.

[Chralt98]

Implement a fake version of the parts of prediction-markets that I need.

The fake part is always flawed, since it doesn't replicate the real functionality.

[maltekliemann]

Solution here is to have both:

• Let's have proper unit tests which use well configured mocks. I'll try to demonstrate how to do this in substrate when testing the liquidity tree.
• Let's put integration tests (which already make up most of our test suite) into the runtime code.

[maltekliemann]

But here's an example of a component that I than can be split off easily (I think): Market account management (contains buy/sell complete set, redeem tokens). Another component would probably be anything relating to disputes. Another one is just for auto-open/auto-close.

[maltekliemann]

Lacks focus.