FakerFactory creates fakes of classes using class-validator decorators for testing purposes.
npm install @galaxyops/faker-factoryFakerFactory creates fakes of classes using class-validator decorators for
testing purposes.
It creates a faker object by first inferring each property's type based the
class-validator decorator. Next, it changes the object to a schema then it
generates fake data for each property. Lastly, the faked object is instantiated
and returned.
Create a fake by calling the FakerFactory.
``typescript
import { FakerFactory } from '@galaxyops/faker-factory';
import { Person } from './person.ts';
const fakerPerson = await FakerFactory.create
`
`typescript
// person.ts or any class that uses class-validator decorators
import {
IsString,
IsInt,
IsBoolean,
IsUUID,
IsCurrency,
Min,
ValidateNested,
} from 'class-validator';
import { Type } from 'class-transformer';
export class Person {
@IsUuid();
public id: string;
@IsString()
@Length(0,50)
@IsOptional()
public firstName: string;
@IsCurrency()
public currency: string;
@IsInt()
@Min(0)
public visits: number;
@IsBoolean()
public passed: boolean;
@IsOptional()
@ValidateNested({ each: true })
@Type(() => Person)
public guests: Person[];
}
`
`ts`
// result
// console.log(fakerPerson);
{
"id": "4cb85e06-1060-4bed-8224-14ec39e0dfa9",
"firstName": "irure in",
"currency": "887.56",
"visits": 24235,
"passed": true
}
FakerFactory accepts a third optional parameter for settings. Settings are used
to change the way the FakerFactory works. Adjusting the settings can be useful
for when writing unit tests on optional fields.
| Property | Description | Possible Values |
| ----------- | -------------------------------------- | ---------------------- |
| probability | probability for faking optional fields | 0, ... 0.5, ... 1 |
| optionals | whether to fake optional fields | true, false, undefined |
`typescript``
const Person = await FakerFactory.create
Person,
{},
{ optionals: true },
);
In typescript object data can be automatically faked based on either: the
property name, property typehint, separate schema, or the decorator schema.
Property names should remain somewhat consistent and fakes can be generated
based on them, this is how Intermock
works. However, it is unreasonable to maintain such a many-to-many relationship
for faking purposes.
Generating values based on property typehinting is less then ideal currently in
typescript due to compiled code being type agnostic and the special tsc
requirement to add such a feature.
Generating fakes purely based on separate schema such as
AJV,
JIO, or
validatorjs works but it is less
readable than a purely decorator based approach.
A class-validator decorators and schema base approach was chosen for the
following reasons:
- Decorators are already present when using class-validation.
- Faker data should not just be fake, it should be valid and meet
class-validator requirements.
- If a class-validator requires a string length faker data should meet that
requirement.
- It is easy to create new class-validator decorators and extend functionality.
- F.I.R.S.T Principles of Testing
- Fake vs Mock
- Faking vs Mocking vs Stubbing
- fakerJs
- class-transformer
- class-validator
- class-validator jsonschema