WIP - Fix failing test due to timezone + hardcoded fixture

[DrewML]

Description

Hey Friends!

I'm from the @magento side of the house, working on some integrations with Adobe I/O.

I wanted to work against the latest aio-cli in master regularly to try and help catch any bugs prior to releases.

When cloning + running tests locally, I currently get one test failure from discover.test.js:

 FAIL  test/commands/discover.test.js
  ● name sort-field, ascending

    expect(received).toMatch(expected)

    Expected substring: "Name Version   Description Published·······
    bar  1.0.1     some bar    January 2, 1970·
    foo  1.0.0     some foo    January 1, 1970·
    "
    Received string:    "Name Version   Description Published·········
    bar  1.0.1     some bar    January 1, 1970···
    foo  1.0.0     some foo    December 31, 1969·
    "

      58 |     return command.run()
      59 |       .then(() => {
    > 60 |         expect(stdout.output).toMatch(
         |                               ^
      61 |           // TODO: add .toMatchFixture
      62 |           // eslint-disable-next-line indent
      63 | `Name Version   Description Published       

      at toMatch (test/commands/discover.test.js:60:31)

It looks like we're not setting an explicit timezone in our call to Date.prototype.toLocaleDateString, so it's defaulting to the local timezone.

I marked this as a breaking change but that's debatable. This fixes unit tests, but it means that dates spit to stdout from the discover command won't be localized.

Some alternatives I considered:

• Do a process.env.NODE_ENV === 'test' check, and use UTC only in tests
• Assert on substrings in the result from stdout, to avoid asserting on the date string

Let me know if you'd prefer one of these options instead.

Related Issue

Motivation and Context

Fix tests for users in other timezones

How Has This Been Tested?

npm test locally

Screenshots (if appropriate):

Before

After

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

Merging #107 into master will not change coverage by %.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #107   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            3         3           
  Lines           69        69           
  Branches        10        10           
=========================================
  Hits            69        69           

Impacted Files	Coverage Δ
src/commands/discover.js	100.00% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a73ca7...bf80115. Read the comment docs.

[shazron]

Hi Drew! Thanks for the PR.
I think a localized date output is important. Therefore I'd prefer the "Assert on substrings in the result from stdout, to avoid asserting on the date string" method to avoid any potential magic branching code in the command itself (even though it would be a known Jest thing via the env var)

[DrewML]

@shazron cool 👍 - sounds like the right choice to me. Will get an update pushed in a little while.

[DrewML]

(wrong button 🤦‍♂)

[purplecabbage]

Thanks @DrewML
I resolved this issue by only testing the actual order of the results instead of string comparing expected date values.

[DrewML]

Hey thanks for finishing this up @purplecabbage - have been playing catch up on some other things.