UI: Fix flaky time-related tests

[hashishaw]

✨ Cleanup Date usage ✨

This has caused headaches during testing, because the value of new Date() constantly changes due to the nature of time. With these changes, we no longer call new Date() within the application, and instead call a utility timestamp.now(). Under the hood, timestamp.now just returns new Date(), but it can be easily stubbed within tests to make the concept of "now" within tests is consistent and much easier to test.

Another change made as part of this PR is replacing all instances of new Date() within tests (when used to generate a UID for engine and secret paths) with uuidv4 which was added as part of 1.13.

NOT part of these changes is swapping out Date.now throughout the codebase. This change is large enough as is, and we can revisit swapping that out at a later time

How to review this
Obviously a lot of files were changed, but most of the changes are fairly simple swaps. I recommend reviewing the code commit by commit, to see similar changes grouped together and larger refactors separated into their own commit. EDIT things got sort of messy at the end there, trying to sort through test failures. Most of the files have 2-3 lines changed, so hopefully it's not too bad 😬

TL;DR How to test components that use time

Let's say you have a component that receives some timestamp from an API, and then renders something different depending on if the timestamp is in the past, future, close, far away, etc. Within the component, we would use timestamp.now() for the current time for comparison rather than new Date().

Then, the test might look something like this:

import sinon from 'sinon';
import timestamp from 'core/utils/timestamp';
// ...other imports

module('Integration | Component | example-component', function (hooks) {
  setupRenderingTest(hooks);
  hooks.before(function() {
    // before all the module tests, we stub timestamp.now to return a static date of our choosing. 
    sinon.stub(timestamp, 'now').callsFake(() => new Date('2018-04-03T14:15:30'));
  })

  hooks.beforeEach(function() {
    // since timestamp.now is being called after we stubbed it, we know that the date will always return 2018-04-03T14:15:30.
    this.now = timestamp.now();
  })

  hooks.after(function() {
    // very important to reset the stub after these tests run, or it will still be stubbed for tests run afterward
    timestamp.now.restore();
  })

  test('it shows the right thing when date is in the future', function(assert) {
    // Now we can use a static date for which to compare to "now"
    this.set('apiDate', new Date('2019-01-01T12:30:00');
    await render(hbs`<ExampleComponent @apiDate={{this.apiDate}} />`)
    assert.dom(this.element).hasText('The API date is next year');
  });
});

If you want the value of now to change depending on the test, you could stub within the test. Note that if you do it this way but call timestamp.now in the beforeEach hook, the value of timestamp.now will not be stubbed at that point, and will give you the actual current time.

[hellobontempo]

so much nicer 🥲

[hellobontempo]

Nice work on this so far! Thank you for tackling this cleanup work! Looking forward to less flaky tests 😍

[hashishaw]

@hellobontempo is this TODO still relevant? The tests seem to pass but I'm not sure if this meant to check more things?

[hellobontempo]

Oish yeah. I noticed this on my last passthrough and wondered the same thing 😅

Among the miscellany of other bugs, I don't think I ever got an answer from the backend on what the expected response in this case (or perhaps forgot to ask). Previously data wasn't available for a customer until the first completed month, but that should no longer be the case.

This test can be deleted! But a good reminder of something that should be taken into account for the latest backend work on activity log testing

[hashishaw]

Might have just been due to running this test locally, but I found that it was expecting "CST" and giving "CDT" (in tests run on main as well). Since the time just switched, I figured testing it this way (making sure there's the expected number of characters) ensures that daylight savings doesn't ruin this test in the future. Other suggestions welcome

[hellobontempo]

I think this makes sense!

[Monkeychip]

So great to see these changes. Thank you for going after this. Quick question, do you think some kind of comment like you have in the PR description can be added to the pattern doc, with a link to this PR?

[hashishaw]

So great to see these changes. Thank you for going after this. Quick question, do you think some kind of comment like you have in the PR description can be added to the pattern doc, with a link to this PR?

Absolutely! Great idea, thanks for the review