Skip to content

Usage of date/date-time in cucumber tests. #185

@gkocak-scottlogic

Description

@gkocak-scottlogic

For context, the swagger specification indicates there are two date types [1]:

And, there are multiple considerations related to testing these two types in BDD.

  1. In one test, these two types are tested by an input as follows.
{ "date": "2013-07-21", "dateTime": "2017-07-21T17:32:28Z" }

But the test operates by comparing both date types with the full date-time type in cucumber features.

And the response should have a property date with value 2013-07-21T00:00:00.000Z
And the response should have a property dateTime with value 2017-07-21T17:32:28.000Z

In a language like Java where these two types are strictly different this comparison is not directly accurate. This would java our code base to include either custom deserialisation mechanisms or do the comparison in a contextual level while ignoring pieces.

Secondly, the tests include the optional miliseconds part. Again this can be solved via contextual comparison but incorporating them in the tests sound like we want to enforce the usage of milis over here.

  1. This one is bigger. In the next test, a field has been given as:
"additionalProperties": { "type": "string", "format": "date-time" }

indicates a date-time property but the test provides the input of

{ "dateOne": "2013-07-21", "dateTwo": "2012-07-21" }

which are date types. Using date and date-time interchangely is not favourable. If we want to support this in the java generator, this would push the code base into incorporating dynamic date/date-time casting/dispatching which can make the code unnecesarily complex.


For summary, the open questions are:

  • date type serialisation is expected to be the same as date-type,
  • serialisation expects the optional miliseconds.
  • one test uses date and date-type interchangeably.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions