-
Notifications
You must be signed in to change notification settings - Fork 8
Description
For context, the swagger specification indicates there are two date types [1]:
- date - full date by RFC 3339, section 5.6- e.g. 2017-07-21
- date-time - full date-time notation RFC 3339, section 5.6 - e.g. 2017-07-21T17:32:28Z
And, there are multiple considerations related to testing these two types in BDD.
- 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.
- 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:
datetype serialisation is expected to be the same asdate-type,- serialisation expects the optional miliseconds.
- one test uses
dateanddate-typeinterchangeably.