We’re considering removing our copy of the standalone Jasmine library that we use for running tests in browser via http://localhost:8080/Specs/SpecRunner.html. The main motivation is to avoid having two copies of Jasmine in CesiumJS - currently we download newer versions from NPM while maintaining a separate Jasmine folder for the browser runner in ThirdParty/.
As an alternative, we’re planning on adding an option to the npm run test task (or maybe a new task) that will enable browser debugging with the Karma browser:
Once this browser opens, you’ll be able to click the “DEBUG” button to open a second tab where the browser dev tools can be used as usual.
We think this will be a good change for keeping the code clean and letting us use Jasmine features that aren’t available in the older standalone browser version. Since this is a sizable change to the debugging and testing process, we’d love to hear your thoughts or any other related suggestions about unit testing.
When implementing new features, it’s common practice to only run a subset of the tests while developing - and the web version of Jasmine makes it easy to do that through string matching. It’s even possible to create bookmarks that are easily accessible for running the same suite of tests. For example, the following URL would run all the tests related to ModelExperimental:
We actually already have two options available for the test task that allow you to filter by strings: --include and --exclude. Though I noticed this is not documented in the testing guide, so we should make sure these (and any other) options are documented regardless of the decision we make here.
Can the new method be run on mobile devices as well? The http://localhost:8080/Specs/SpecRunner.html works on mobile devices out-of-the-box just like that and I think this is a great feature to it.
@v12424124_34 With the singleRun Karma option set to false, running the gulp “test” task will start a server any local device can connect to. There may be some extra work to access the debugger on mobile devices.
If you used the SpecRunner on mobile, do you connect to your local CesiumJS server from another device after running npm run startPublic, or did you have the server set up on the mobile device itself? If you have experience debugging/testing on mobile we’d be interested to hear what your workflow is like.
We did run after running npm run startPublic on desktop and have mobile on the same wifi. This proves to be super usefull. I hope the new proposed method will include this possibility.
You should also consider services like https://bitbar.com/ in this context, where you can run public http pages on farm of devices => especially there I would say running server instead of just plain public url would be way more difficult.
I feel that this is a good change to “promote” one bugfix a bit:
I fixed that by using the mentioned concepts and that was a tough one…
I would be thrilled to see the whole ThirdParty folder go up in smoke – the ecosystem has a perfectly robust package manager and dependency description mechanism, and IMHO there’s no reason to go around shipping other peoples’ code with yours.
As for Karma specifically, as long as you have script tasks for common test runner scenarios I’m happy with it. I couldn’t get --include to work, but you can always use spec-level controls like fit / fdescribe (and xit / xdescribe).
Certainly glad to see less code in ThirdParty, we just found that the command line interface is a bit more limited of a workflow than the old SpecRunner. Most notably, the VSCode debugger integration was useful and the SpecRunner UI listed all the tests nicely before running anything.
):