Current testing strategy uses dependency injection to capture reference to mapbox class instances.
Due to the somewhat chaotic nature of event triggering and timing in the mapbox suite, this is an unreliable approach. It limits how much we can test, introducing gaps in coverage.
The new strategy should be to stub in the mapbox-gl dependencies entirely with mocks. This will allow testers to:
Include assertions on mapbox-owned methods by stubbing those methods, for specific tests
Artificially trigger mapbox-gl event callbacks
This will set us up for success for addressing bug fixes/regressions. This will also enhance stability.
Some drawbacks are that stubbing mapbox-gl will be fairly extensive, and will be sensitive to API changes from mapbox-gl. Artificially triggering event callbacks also assumes things about the chains of events that happen downstream of "real" clicks. The tradeoff is that the net coverage gap is marginally higher.
Current testing strategy uses dependency injection to capture reference to mapbox class instances.
Due to the somewhat chaotic nature of event triggering and timing in the mapbox suite, this is an unreliable approach. It limits how much we can test, introducing gaps in coverage.
The new strategy should be to stub in the mapbox-gl dependencies entirely with mocks. This will allow testers to:
This will set us up for success for addressing bug fixes/regressions. This will also enhance stability.
Some drawbacks are that stubbing mapbox-gl will be fairly extensive, and will be sensitive to API changes from mapbox-gl. Artificially triggering event callbacks also assumes things about the chains of events that happen downstream of "real" clicks. The tradeoff is that the net coverage gap is marginally higher.