feat(testlab): add a new helper toJSON

[bajtos]

Implement a helper function to convert an object (e.g. a Model instance) to a data object representing JSON version of the input object.

Specifically, properties set to a value that cannot be represented in
JSON (e.g. undefined) are removed from the result.

Checklist

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site testlab's README was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[raymondfeng]

We should say JSON format or JSON encoding instead of transport.

[raymondfeng]

The method name is a bit misleading. It tricks me to think about the argument is a JSON string.

What about asJSON() or toJSON()?

Do we want to restrain the argument to be an object? What about any?

We need to deal with the case where value is undefined.

JSON.parse(JSON.stringify(undefined)); // SyntaxError: Unexpected token u in JSON at position 0

The return type is incorrect, for example:

// Customer is a class with `getFullName()` method.
const customer: Customer = await this.repo.findById('c001');
const json = deserializedFromJson(customer); // TypeScript infers the return type as `Customer`
json.getFullName(); // The function does not exist but TypeScript cannot catch it.

I propose that we change the method to be:

export function toJSON<T extends object>(value: T): DeepPartial<T> { // ... }

[virkt25]

+1 to using either asJSON or toJSON ... with a slight preference for toJSON.

// Customer is a class with `getFullName()` method.
const customer: Customer = await this.repo.findById('c001');
const json = deserializedFromJson(customer); // TypeScript infers the return type as `Customer`
json.getFullName(); // The function does not exist but TypeScript cannot catch it.

I don't think json.getFullName(); is a valid use of this as the intention of this method is to act as a helper to allow comparison of an object to the value you would get from a rest api ... which is the use case for testing (and the inspiration for this helper method). One should just do customer.getFullName() instead of converting to JSON and then trying to treat it as a class.

Considering the above maybe a better name we can use is modelToJSON?

[raymondfeng]

@virkt25 Please note by the current signature, deserializedFromJson(customer); returns a Customer, which has getFullName(). As a result, TypeScript thinks json.getFullName() is valid use but the getFullName does not exist on the object.

[virkt25]

Implementation LGTM. Just need to agree on a name as per the comments.

[bajtos]

export function toJSON<T extends object>(value: T): DeepPartial<T> { // ... }

I think this isn't going to really fix the problem, because DeepPartial will only make all methods optional - it is not going to hide them from the result.

I solved the problem by returning a generic object type. This type does not have any properties nor methods beyond built-in Object.prototype. This is good enough for the use case of comparing data via deep-equal.

I have also renamed the helper function to toJSON and added support for other value types, from undefined and null to scalar types like numbers & strings.

PTAL again, LGTY now?

[raymondfeng]

@bajtos Please address my latest comments.

[raymondfeng]

So far, @loopback/testlab does not depend on @loopback/repository. Are we ok with adding this dependency?

No need to use @model. Just plain JS classes will do.

[jannyHou]

LGTM 👍

[bajtos]

@raymondfeng added more tests as you requested and simplified the actual implementation by wrapping the input value in an object property. LGTY now?

[raymondfeng]

Great work!