Comparing BABYLON Nodes results in out of memory

Questions
1

In one of my jasmine specs I wrote

expect(parentModuleNode.getChildren()[0]).toEqual(this.sceneRecordingExtension.scene.getNodeByID("3210625052"));

Here parentModuleNode is a BABYLON.Node and this.sceneRecordingExtension.scene is a BABYLON.Scene

The problem with this call is that it results in out of memory. Chromium was kind enough to tell me this after a couple of minutes waiting.

So the questions is, is this by design? I have work around this with

expect(parentModuleNode.getChildren()[0].name).toEqual("3210625052")

But I decide to post it here for future references by people trying to “compare BABYLON nodes with Jasmine”

Update:
I suppose and assume it is by design, but it is Jasmine design as it is deep comparing objects and BABYLON could do nothing. Yet, nice to know.

2

This seems more like an engineering philosophy decision, but I would suggest that a test like this gives very little meaningful coverage. If you have a method that copies one object to another then just feed it a mock object in your tests and compare the two. Don’t use actual Babylon scenes in your tests, otherwise you’re just duplicating tests already written by the Babylon team. If it’s difficult to test your code with mock objects then sometimes that’s a sign that your method is doing too many things and could benefit from a refactor.

3

Thanks for the suggestion. Mock are not really a solution here. The code is a fragment from a bigger picture where we are editing a babylon scene. So I need to test that our editing tools have done their job correctly.

4

Sure, but in a unit test you’re really just confirming that a known data type is returned given a known input, and then you can write up all the corner cases to confirm that nothing is broken. My personal opinion is that any method should accept a mock object and be testable and I never use the actual results of an external library’s functions.

Anyway, that’s what I’d do.

ETA: If you really need to, you can allocate more RAM to your tests but that seems more like a bandaid solution.

5

Been there, done then. Reduced doing it a few years ago. There are places for mock but not in this scenario (its bigger than what I have shared).