Add frame router tests #287
Conversation
| envData: ENV_DATA, | ||
| }; | ||
| //@ts-ignore | ||
| expect(router._envData).toEqual({ |
There was a problem hiding this comment.
"_envData" is accessible here? I thought it was a private variable
There was a problem hiding this comment.
In TypeScript private is only meaningful within the type system. Because TS has to compile to vanilla JS, which has no direct concept of private, it just becomes a regular property on the object. That means it's accessible in tests by disabling the type checks for that line.
It's not a pattern I'd generally recommend though, and on the next major release when we're doing significant refactors, we should look for ways to make this testable without having to ignore type checks.
|
Looks like I accidentally updated package-lock.json to point at our internal npm repo. I'll fix that and update the PR today. |
This resolves some bugs with testing custom element code
…ehavior This behavior is somewhat inconsistent and should be re-worked in the future, but this will let us make small improvements and bugfixes without regressing current behavior in a way that could break existing usage.
MattCheely
force-pushed
the
add-frame-router-tests
branch
from
3b64b67 to
8abfc2e
Compare
In looking at #271, I discovered some corner cases where behavior was changing. I was also able to get unit testing working for the underlying behavior, so I've opened the PR to add the unit tests and verify they are correct for the current release. This will capture the (admittedly inconsistent) current behavior of the library. We can merge this and use it to refine the work in the query fix PR to ensure no regressions.