Open lucasteles opened 1 year ago
Hi @lucasteles; could you give me a few concrete examples of what you're trying to accomplish? Full examples that can compile would help a lot.
I'm having some trouble understanding your request. The following seems to work fine:
void Main()
{
var builder = new Faker<User>()
.RuleFor(x => x.Email, f => f.Person.Email)
.RuleFor(x => x.Age, f => f.Random.Int(18, 50))
.RuleFor(x => x.Name, f => f.Person.FirstName);
builder.Generate().Dump();
}
public class User
{
public string Name { get; init; }
public int Age { get; init; }
public string Email { get; init; }
}
If you're finding that the following is too complex or unsightly:
var builder = new Faker<User>()
.RuleFor(x => x.Age, f => f.Random.Int(18, 50))
.RuleFor(x => x.Name, f => f.Person.FirstName)
.CustomInstantiator(f =>
new User(f.Person.Email)
{
Name = ...,
Age = ...,
});
Consider refactoring and using a non-typed Faker
:
void Main()
{
User GenerateUser()
{
var f = new Faker();
var user = new User(f.Person.Email)
{
Name = f.Person.FirstName,
Age = f.Random.Int(18,50)
};
return user;
}
GenerateUser().Dump();
}
public class User
{
public User(string email) => Email = email;
public string Name { get; init; }
public int Age { get; init; }
public string Email { get; init; }
}
As you've indicated, Faker<T>
has some limits before object design complexity gets in our way; and in such cases, we should consider a non-typed Faker
as a suitable and reasonable alternative.
The typed Faker class is great to create complex builder scenarios, the power of defining the shape of the type in parts as necessary is one of the best things to solve problems like test scenarios.
Something like this:
Things get a bit complicated when the Type has a complex constructor or a mix with required properties:
In this case, we kinda lost the power of member composability. If it was a custom builder I would have to create fields to hold values for the
CustomInstantiator
etc.So would be nice to have a way to get the shape of the data without constructing the actual Type
A generic way to solve this could be to have a new method like
GetJsonObject
, which for the case above could be something like:So it could be used on the complex constructor, preserving the member composability:
Another solution would be use Castle
DynamicProxy
to maintain the type contract butmocking
the property values:Is the feature something that currently cannot be done? I don't think so
What alternatives have you considered? Customize the Faker inheriting from it, or just create/initialize all the properties manually
Is this feature request any issues or current problems? No
Has the feature been requested in the past? No
If the feature request is approved, would you be willing to submit a PR?
Yes