The actual test is pretty simple though it requires Chrome to run. This is because Chrome comes with some nifty flags that let in browser tests do things other browsers can’t.
Where I currently work, we use the Karma test runner for testing so setting up different browsers is as easy as installing an npm module and adding the browser to the build with the given flags.
After adding Chrome to your test runner, you will want to add the actual memory test. The memory test consists of a few parts.
- A header that guards against browsers that don’t support the features we need.
- A function for getting a memory profile
- An object that tracks memory profiles over time (optional though useful)
- The portion of your application you want to profile between calls to
profile.sample(). In my case, this was the loading of a particularly heavy WebGL scene whereby a 50MB+ model was loaded in addition to many other operations where it would then be “disposed” of and all references to created objects broken (or we hope!).
- The test assertions that are specific to the memory requirements of your application. Some sample assertions are given below (in this case using the chai
This test has saved me a couple of times though isn’t bullet proof. Chrome and Firefox are very different beasts when it comes to memory management and, with specific “experimental” technologies like WebGL (come on, we already have WebGL2!), Firefox really likes to leak. This is the point where you start using the memory profiling tools native to your browser (Firefox profiler and Chrome Profiler). I prefer Chrome’s toolset just because it gives you so much more control but Firefox’s will probably get there with time.