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

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

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)

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.

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

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

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'),
});

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.

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.

@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),
})

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).

Hi @thiagodp @CoreyKovalik,

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