Tests for new session/slot status handling flow
Closed this issue · 3 comments
this is laid out as described, but needs to be tested with mock document snapshots in jest etc etc
the list (for now)
What has ended up coming out of this is a large change in how we handle the local development environment, namely we use emulators now:
https://firebase.google.com/docs/emulator-suite
We emulate the entire firebase suite (and a couple external APIs) to allow for local development to be (almost) entirely contained inside localhost. Doing so eliminates the main problem that turned out to be breaking the aforementioned tests: Jest, running locally, has no way to wait for the web calls to external Firebase servers. There would be no way for it to know anything about their state unless these services were local like the code being stepped through.
Now that the emulators support all of the services we use, we can set these up and start using actions on the emulator (or provana-tools pointed at the emulator) to test firestore trigger functions etc, and run either unit tests or breakpoint debugging on anything in the api.
If you're not working on a unit test, you can debug without having to create mock data by running the emulators with the --import flag, importing the directory (whose names will begin with a period) corresponding to the point in a lifecycle you want to start from. e.g. session potential, session published with unbooked slots, etc. It will also package all the auth users and everything else you need to fully mock this functionality on live firebase.
Of the two big trigger handlers, SlotStatusHandler and SessionStatusHandler, the following methods are tested:
- session onPublish
- slot onHolding
the next step is knocking the rest of these out by debugging the code that's already laid down for them, then maybe sometime after the fact adding in the unit tests for the status handlers running against the emulators.
Here we are two weeks later with a very mature system for this. The general paradigm is:
user-hit endpoint to cancel (or whatever) to a session/slot:
- runs safety checks if necessary by calling Stripe servers for acct/cust/payment info
- the ONLY THING that happens in these endpoints model-wise should be updating a status.
Everything else is handled in status watchers, since that allows for a deeper level of granularity to handle different cases of the same action efficiently. i.e. we can look at before and after status and react off that, rather than just having one big endpoint that cancels etcetc