I wanted to understand how the ObjectNode class works, so I wrote a pretty big test file that exercises it, primarily calling things from the constructor.
I left a comment at the top of the test file to this effect, but I want to clarify that this test is not intended to be a regression test. In many ways, it's testing internals of the library that shouldn't be considered part of a regression test suite.
I think in many ways, these assertions get exercised by every other test that uses MST from the user-facing API. But I learned a lot by working with this internal API on my own like this.
If anyone finds that these tests break in the future, I think it's a possible yellow flag that something has changed, but if the rest of the test suite is passing, then it's probably a false negative and just too tightly coupled to implementation.
You'll also notice I had to fudge some TypeScript in the tests themselves. The internals aren't typed to be used the way I'm using them, but I was pretty sure I could get them to behave how I wanted, so I asked TypeScript to let me break the rules a few times.
What does this PR do and why?
I wanted to understand how the
ObjectNodeclass works, so I wrote a pretty big test file that exercises it, primarily calling things from the constructor.I left a comment at the top of the test file to this effect, but I want to clarify that this test is not intended to be a regression test. In many ways, it's testing internals of the library that shouldn't be considered part of a regression test suite.
I think in many ways, these assertions get exercised by every other test that uses MST from the user-facing API. But I learned a lot by working with this internal API on my own like this.
If anyone finds that these tests break in the future, I think it's a possible yellow flag that something has changed, but if the rest of the test suite is passing, then it's probably a false negative and just too tightly coupled to implementation.
You'll also notice I had to fudge some TypeScript in the tests themselves. The internals aren't typed to be used the way I'm using them, but I was pretty sure I could get them to behave how I wanted, so I asked TypeScript to let me break the rules a few times.
While testing, I ran into https://github.com/mobxjs/mobx-state-tree/issues/1989 and patched it, so this technically includes a fix. It's a minor change and well tested here and elsewhere.
Steps to validate locally
This won't impact users (other than patching a minor error, https://github.com/mobxjs/mobx-state-tree/issues/1989), so I'm going to go ahead and merge it in.
yarn testshould pass.