test: add test cases for parse date and random object

[rhuanbarreto]

This PR is still failing tests. This is to show that the complex object case is failing.

[mrctrifork]

Those are edge-cases that cannot be solved.

The problem is that you'd require the TypeBox schema on Eden's side of things to be able to decode a JSON into it's declared schema because in JSON there's no way to tell apart a Date from a plain string.

Therefore Eden does a best-effort and if a string looks like an ISO8601 Date it goes ahead and parses it into a Date because that's what 99% of developers would do.

If you need the string on the client-side you can still call toISOString()

[rhuanbarreto]

I agree that the "smartness" of checking if a value is a date by regexing it is fair enough.

But at least the "get random object" test should pass because 99% of the developers as you say would expect a date inside an object coming as a Date object from a JSON response. Same for the WebSocket failure.

[NanoSpicer]

Havent fully gone through the code as I am on the go, but I'll check it later. Should be easy enough to fix

[mrctrifork]

I just cloned your fork and ran the tests.

I do believe the test case you wrote is still one of these edge-cases that cannot be solved; as the toEqual expects property g to be a string but eden parses that into a Date since the value of g looks like a Date. Therefore a string representing a Date is not equal to an actual Date object.

As I mentioned in my previous comment; you cannot really solve this ambiguity problem (whether to parse a string that looks like a date or not) without the actual specification TypeBox schema definition.