Implement Jest and Enzyme testing frameworks

[dwalintukan]

No description provided.

[BernardHan]

Large Workload:

• stores/WalletStore.js [on hold]
• scenes/Event/store.js
• scenes/CreateEvent/store.js Harrison

Medium Workload:

• stores/AllEventsStore.js Bernard

• stores/BotCourtStore.js

• stores/GlobalStore.js

• stores/models/* Bernard

• scenes/Wallet/History/store.js [on hold]

• scenes/QtumPrediction/store.js [after alleventstore done]

• scenes/Activities/Withdraw/store.js [after alleventstore done]

• scenes/Activities/ResultSetting/store.js [after alleventstore done]

• scenes/Activities/Finalize/store.js [after alleventstore done]

• scenes/Activities/ActivityHistory/store.js

• components/PendingTxsSnackbar/store.js Harrison

Small Workload:

• stores/RefreshingStore.js

• stores/UiStore.js

• components/GlobalSnackbar/store.js

• components/WalletUnlockDialog/store.js [on hold]

[BernardHan]

@dwalintukan I have organized what files we will be testing on.
Harrison and I want to pick files to test on our own and label in the above comment which file belongs to whom.

Or do you think each file worth to be an issue? Or do you have a better suggestion about how we can manage this?

[dwalintukan]

@BernardHan
Yes, models need to get tested too. Those tests are pretty critical to make sure the data gets set right and also to test the funcs that change the data inside those models. If you think about it, most data is derived from the models in the UI layer.

As for organization, let's do it this way. When you start on a store, create an issue then and place it in the In Progress column of the sprint board. That we you know which ones are being worked on at the moment.

You can also pre-assign the stores to test for each of you, but would also like to have an in-progress issue on the sprint board for tracking as well.