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.
- 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:
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.
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.
{ "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.
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.
indicates a
date-timeproperty but the test provides the input of{ "dateOne": "2013-07-21", "dateTwo": "2012-07-21" }which are
datetypes. 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,dateanddate-typeinterchangeably.