Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date API Proposal #117

Closed
thiagodp opened this issue Apr 11, 2018 · 14 comments · Fixed by #229
Closed

Date API Proposal #117

thiagodp opened this issue Apr 11, 2018 · 14 comments · Fixed by #229

Comments

@thiagodp
Copy link
Contributor

thiagodp commented Apr 11, 2018

Feature Request

Description:
API for Date matchers. Some matchers are inspired by Jasmine Matchers.

Possible solution:

Jasmine-like matchers:

expect(date).toBeDate(); // Matcher added
expect(date).toBeValidDate();  // Matcher added

expect(date).toBeAfter(otherDate); // Matcher added
expect(date).toBeBefore(otherDate); // Matcher added

expect(object).toHaveDate(memberName);
expect(object).toHaveDateAfter(memberName, date);
expect(object).toHaveDateBefore(memberName, date);

Additional matchers:

expect(date).toBeAfterOrEqualTo(otherDate); // or toBeGreaterThanOrEqualTo
expect(date).toBeBeforeOrEqualTo(otherDate); // or toBeLessThanOrEqualTo
expect(date).toBeBetween(startDate, endDate);
expect(date).toDiffInDays(otherDate, days); // e.g., expect( '12/25/2018' ).toDiffInDays( '12/24/2018', 1 );

expect( date ).toHaveDay( day );
expect( date ).toHaveMonth( month );
expect( date ).toHaveYear( year );
@mattphillips
Copy link
Member

Nice one @thiagodp I like these a lot! Fancy sending a PR for any of them? 😄

@thiagodp
Copy link
Contributor Author

Hello @mattphillips ,
added #118 with toBeDate(). It's a first step, but I'll try to add more soon.

tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 2, 2018
gillesdemey added a commit to gillesdemey/jest-extended that referenced this issue Jun 2, 2018
tejasbubane added a commit to tejasbubane/jest-extended that referenced this issue Jun 16, 2018
mattphillips pushed a commit that referenced this issue Jul 30, 2018
* adds toBeBefore and toBeAfter matchers (#117)

* updates documentation

* adds gillesdemey to contributors

* encode timezone into date constructors
@CoreyKovalik
Copy link
Contributor

CoreyKovalik commented May 4, 2019

I believe the following shouldn't pass, since 0 value unix codes are common bugs

This currently passes, but I believe should fail:

expect(new Date(0)).toBeValidDate()

That or add matchers to test valid/recent unix, so we can avoid code like this to test timestamps were created on a resource:


expect(someUnixTimestamp)
    .toBeNumber()
    .toBeLessThan(Date.now())
    .toBeGreaterThan(Date.now() - 5000)
    .not.toEqual(0)

@thiagodp
Copy link
Contributor Author

thiagodp commented May 4, 2019

Hi @CoreyKovalik, I think I disagree with you about 0 to be an invalid value. The Date API defines that argument as "an integer value that is the number of milliseconds since 1 January 1970 UTC". So, there is nothing wrong with it.

Whether an application could not accept it in order to avoid some kind of problem, a programmer should document that with a test case. However, the (Jest-extended) library should allow it, since it is an acceptable value for a Date.

@CoreyKovalik
Copy link
Contributor

@thiagodp Was thinking along the lines of the same thing. Would be nice to have a similar set of matchers for Unix timestamps

@thiagodp
Copy link
Contributor Author

thiagodp commented May 4, 2019

@CoreyKovalik yes, it would be useful to have such matchers

@dandv
Copy link

dandv commented Jun 15, 2019

I'd like to propose a match for a timestamp being "within the last X ms". This is useful, for example, when testing that files like "createdAt" or "updatedAt" were properly updated within about the timestamp of the text.

I'm currently using

expect(Date.now() - object.updatedAt).toBeLessThan(10 * 1000);

Proposed matcher:

expect(object).toMatchObject({
  // ...
  updatedAt: expect.withinLast('10s'),
});

@RobertFischer
Copy link

Anyone working on this? @thiagodp @mattphillips @CoreyKovalik ? If not, my work (@k4connect) is giving me some time to get these in, since they'd be useful for us.

@hansal7014
Copy link
Contributor

Hi All,
I am new to open source development and would like to work on the 'toBeBetween' matcher. I can start working on this feature unless somebody is already working on it.
Thanks.

@CoreyKovalik
Copy link
Contributor

CoreyKovalik commented Sep 9, 2019

@RobertFischer, @hansal7014,

I'm not working on any of these currently, but I can share what pattern I've been using as a solution in production tests.

const now = Date.now()
const response = fooFunctionToTest()
const nowDelta = Date.now() - now

expect(response.timestamp).toBeGreaterThanOrEqual(now)
expect(response.timestamp).toBeLessThanOrEqual(now + nowDelta)

It's been working for me for testing side effects in integration tests for values such as createdAt and updatedAt

I secure this further with validating timestamps by extending Joi as well.

const joiUnixTimestamp = (joi) => ({
    name: 'unixTimestamp',
    base: joi
        .number()
        .integer()
        .min(0),
})

@thiagodp
Copy link
Contributor Author

thiagodp commented Sep 9, 2019

Hi { @RobertFischer , @hansal7014 , @CoreyKovalik }, I'm not working on any of these either.

Suggetion (@hansal7014 ): toBeBetween(startDate, endDate) could be defined as toBeAfterOrEqualTo(startDate) and toBeBeforeOrEqualTo(endDate).

@hansal7014
Copy link
Contributor

Hi @thiagodp @CoreyKovalik,

I'll start working on these matchers. Thanks for the suggestions.

@JamieMason
Copy link

Hi @thiagodp,
A newer typescript version of Jasmine Matchers is at expect-more-jasmine and there is also a version for Jest is at expect-more-jest. Some of the date matchers discussed here are featured there, feel free to take them if there is anything useful there.

@thiagodp
Copy link
Contributor Author

Nice, @JamieMason.
Good work, @SimenB !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants