Currently to test we use the StubBackend project, which implements a server which serves up phony blockchain and backend data and provides stubs for the mutating functionality. Completely orthogonal to this is the StubChainAdaptor, which implements a similarly stubbed interface. Currently these two are completely independent, thus no chain-mutating changes can have a meaningful effect, for example, if the UI requests the StubBackend create a contest on the chain, the StubChainAdaptor is oblivious to this so there's no way to test that the app is properly finding the new contest on chain and displaying it.
To improve this situation, a closed-loop testing stub should be created, such that the testing backend is kept inside the application process rather than over the network. The chain adaptor implementation and the backend implementation should be connected so that mutating changes to the 'chain' are observed by both, thereby 'closing the loop' and allowing the UI to make changes and see their results.
As an added benefit, this gets rid of the requirement to have the StubBackend running in the background in order to test the app.
Currently to test we use the
StubBackend
project, which implements a server which serves up phony blockchain and backend data and provides stubs for the mutating functionality. Completely orthogonal to this is theStubChainAdaptor
, which implements a similarly stubbed interface. Currently these two are completely independent, thus no chain-mutating changes can have a meaningful effect, for example, if the UI requests theStubBackend
create a contest on the chain, theStubChainAdaptor
is oblivious to this so there's no way to test that the app is properly finding the new contest on chain and displaying it.To improve this situation, a closed-loop testing stub should be created, such that the testing backend is kept inside the application process rather than over the network. The chain adaptor implementation and the backend implementation should be connected so that mutating changes to the 'chain' are observed by both, thereby 'closing the loop' and allowing the UI to make changes and see their results.
As an added benefit, this gets rid of the requirement to have the
StubBackend
running in the background in order to test the app.