So I think the answer here is to get a sessionStorage mock going. We can
either find one and add it to devDependencies or I can whip one up.
Upgrading the testing framework is probably worthwhile, but it may be out
of scope for this effort. We could investigate Jest, as I've had success
with that in the past. Either way, a big test refactor would be in order.

Rob

On Thu, Sep 12, 2019 at 1:24 AM Joshua Poore <poor...@apache.org> wrote:

> @Rob
>
> Following up:
>
> I think the issue is that jsdom v9 has no concept of sessionStorage, so
> when getInitialSettings runs, we have a complete failure of UserALE.js
> within the jsdom environment. This would affect .options and .log APIs. I
> haven’t pushed more work on this, just have done some experimentation
> locally. But, if you re-work the getSessionId function to work outside of
> the getInitialSettings function and simply pass a variable into it, which
> is super ugly, you’ll get a new test failure error message indicating that
> sessionStorage is undefined. I didn’t push this because its not the best
> implementation that we should be working around. The reason why we’re not
> seeing the same error in the implementation on branch is because the
> getSessionId function is called from within getInitialSettings, so we see a
> report of .options being undefined.
>
> I’ve documented this here:
> https://issues.apache.org/jira/browse/FLAGON-451 <
> https://issues.apache.org/jira/browse/FLAGON-451>, which is where I’ve
> moved comments to from issue:
> https://issues.apache.org/jira/browse/FLAGON-441 <
> https://issues.apache.org/jira/browse/FLAGON-441>
>
> We have two options: there are some patchy things we can do with other
> modules (described in the ticket), which are still challenging given how we
> use jsdom.env, OR we can update our testing framework to jsdom v12
> (supports sessionStorage) which is also a lot of work.
>
> Rob (+ others) — I’m willing to put in some elbow grease on updating to
> jsdom v12. We may also need to update chai, but frankly our unit-testing
> framework is out of date and we’ll be faced with harder updates in the
> future. If I push some commits on this, will you be able to support?
>
> Josh
>
> > On Aug 12, 2019, at 2:21 PM, Joshua Poore <poor...@me.com.INVALID>
> wrote:
> >
> > I did some more testing that I’ll document in the next few days.
> >
> > I think the issue is that JSDOM has no concept of window.sessionStorage.
> Which ever process calls the function I wrote breaks with a Type Error
> undefined, but if the function is pulled out of the context of
> getInitialSettings it looks like we get an error specific to
> sessionStorage. I’ve tried pulling in some add’l npm packages meant to
> define storage elements, but haven’t had success yet. Then again, haven’t
> had bandwidth to try really hard yet.
> >
> > Thanks Rob. More findings soon.
> >
> > Joshua Poore
> >
> >
> >> On Aug 12, 2019, at 10:23 AM, Rob Foley <r...@apache.org> wrote:
> >>
> >> I looked through the branch/issue and tried playing around with the
> code a
> >> bit. It seems like the userale script is not being added to the JSDom
> >> environment. Our custom resourceLoader (found in test/testUtils.js) is
> >> being ran, and is getting the correct content, however at some point
> JSDom
> >> is not actually putting that content into the page. I tried downgrading
> >> JSDom to an earlier version with no luck, so I am not sure if there is
> >> something else going on.
> >>
> >>> On Sat, Aug 10, 2019 at 12:47 AM Joshua Poore <poor...@apache.org>
> wrote:
> >>>
> >>> Rob (or anyone else):
> >>>
> >>> any thoughts?
> >>>
> >>> issue: https://issues.apache.org/jira/browse/FLAGON-441 <
> >>> https://issues.apache.org/jira/browse/FLAGON-441>
> >>>
> >>> branch:
> >>> https://github.com/apache/incubator-flagon-useralejs/tree/FLAGON-434 <
> >>> https://github.com/apache/incubator-flagon-useralejs/tree/FLAGON-434>
> >
>
>

Reply via email to