OZtree
OZtree copied to clipboard
OneZoom
Unit testing for tours
I'm copying in some earlier notes from @lentinj on this question....
~~I can think of 2 ways of reading this. ~~
~~A chromedriver-based tour test that, for a supplied tour:~~
- ~~Runs through each tourstop checking at all stages the tour is consistent~~
- ~~At least one tourstop is visible, or there is zooming~~
- ~~The tour halts~~
- ~~Takes a screenshot (or video) so you can inspect for layout purposes~~ ~~Obviously we can test some edge cases here, but I don't think that should be the emphasis.~~
The other way of reading this is actual unit tests for Tour.js, that run with a mocked onezoom and mocked DOM. This will be a more effective way of testing edge cases like a scroll event firing mid-tourstop-wait since you can have full control of time. We can ensure that bits parsed out of the JSON end up in relevant places, etc. As part of this it'll be worth removing the various jQuery instantiations, doesn't look like they're doing anything that isn't easy in vanilla DOM nowadays and saves having to rig up jQuery to the JSDOM, which is always more fragile than it should be.
isn't easy in vanilla DOM nowadays and saves having to rig up jQuery to the JSDOM
It's usage of jQuery is more subtle than first glance, since TourStop stores a jQuery-fied DOM object to operate on. Regardless, hooking up jQuery to JSDOM seems to be working, so maybe it isn't as painful as it used to be.
We can still gently remove jQuery from Tours if need be, but having unit tests to do so would make life a lot easier.
I forgot to push what I had done for tour unit testing.
As it is it's not particularly useful, it was written before Tour.js was reworked to work with HTML tourstops. However, it's still a useful starting point for writing tests, which will be invaluable when it comes to integrating audio / video.
Note I'm assuming this ticket is about unit-testing our code, rather than a tour-validation mode. That's covered elsewhere, e.g. https://github.com/OneZoom/OZtree/issues/603
Also note that the controller CRUD unit tests were covered in #562
Note I'm assuming this ticket is about unit-testing our code
Yes, exactly. There are many things a user might want to do when going through a tour, stopping at certain places, going back, registering to the audio, etc. We need to make sure all these transitions and interruptions are handled gracefully.
As you say, the controller backend stuff is handled elsewhere.
The above provides enough unit-testing framework to be able to, given a tour HTML, poke it about and run through the tour. The onezoom object is mocked so we can decide ourselves when flights finish, etc.
Obviously this isn't full coverage, but enough to get going with and add tests as we go for audio, etc.