Some of the unit tests are too slow
See original GitHub issueCurrently it takes ~40s to run the test suite. It used to be much faster, but we added a lot of unit tests since then and some of them are bottlenecks. We can use karma-time-stats-reporter
plugin to discover which of the tests are slowing down the suite. Here’s the list of the slowest ones:
4707ms Map #flyTo move to requested center and zoom, and call zoomend once
2877ms Map #flyTo flyTo start latlng == end latlng
2862ms TileLayer number of kittens loaded Loads 290, unloads 275 kittens on MAD-TRD flyTo()
2699ms GridLayer number of 256px tiles loaded in synchronous animated grid @800x600px Loads 290, unloads 275 tiles on MAD-TRD flyTo()
1329ms ImageOverlay #getCenter should open popup at the center
808ms Popup L.Map#openPopup moves the map over a long distance to the popup if it is not in the view (keepInView)
683ms Map.ScrollWheelZoom changes the option 'wheelPxPerZoomLevel'
612ms Path #events can add a layer while being inside a moveend handler
358ms Map.ScrollWheelZoom changes the option 'wheelDebounceTime'
314ms LineUtil #polylineCenter computes center of a small line and test it on every zoom
309ms Map.ScrollWheelZoom zooms out while firing 'wheel' event
307ms Map.Keyboard plus/minus keys zoom in
306ms Map.ScrollWheelZoom scrollWheelZoom: 'center'
306ms Map.Keyboard does not move the map if disabled no move north
306ms Map.Keyboard does not move the map if disabled no zoom in
306ms Map.Keyboard arrow keys move the map west
305ms Map.Keyboard plus/minus keys zoom out
305ms Map.Keyboard arrow keys move the map east
305ms Map.Keyboard arrow keys move the map north
303ms Map.Keyboard arrow keys move the map south
297ms Map.ScrollWheelZoom zooms in while firing 'wheel' event
266ms Map #containerPointToLayerPoint return point relative to LayerPoint
263ms Map.DoubleClickZoom doubleClickZoom: 'center'
260ms Map.DoubleClickZoom zooms out while dblclick and holding shift
256ms Map #layerPointToContainerPoint return point relative to ContainerPoint
252ms TileLayer #setUrl fires only one load event
244ms Map.DoubleClickZoom zooms in while dblclick
220ms Control.Layers sortLayers keeps original order by default
193ms Map.Drag touch events reset itself after touchend
191ms Map.TouchZoom Dragging is possible after pinch zoom
It would be nice to fix some of these if they don’t depend on such a long running length. Faster test suite means less friction when developing.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
How slow is too slow for unit tests? - Stack Overflow
A unit test that takes 1/10th of a second to run is a slow unit test... If [unit tests] don't run fast, they...
Read more >9 Ways To Make Slow Tests Faster - Semaphore CI
At Semaphore, we've seen our fair share of tests and have identified 9 ways to make your slow tests faster.
Read more >Unit tests running slow - does not seem to use all cores
Adding some more information. It seems to start out fast, using >90% CPU and running 4 of 5 tests in parallel, but then...
Read more >Unit Tests Slow Me Down - Medium
Actual nitty gritty debugging is faster when you're doing it via unit test rather than stepping through a debugger. Most debugging time is...
Read more >Unittest run all tests is extremely slow #17295 - GitHub
Running my particular test suite takes 1.2s while running the tests using the vscode extension takes at least several seconds.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think this is all the savings I’ve found from all >100ms tests. The ones that remain I believe are bottlenecked by animation frames, as mentioned above.
Reductions so far:
A good chunk of our tests appear bottlenecked by the speed that Chrome running in headless mode will deliver animation frames. I’ve noticed this looking into tests using Leaflet/prosthetic-hand, as they seem to run twice as fast in a non-headless browser.
The tests overall do run a lot quicker in a windowed instance of Chrome. I suspect this is due to GPU acceleration.
I’m not sure if we want to do anything with this information. I don’t think it’s practical to run a windowed version of Chrome every time we run the tests, as the window popping up is quite disruptive. Nevertheless I wanted to document the finding 😃