Builder Patterns for more flexible dataprep about testingpatterns HOT 3 OPEN

How to handle random vs. customized values? Unlike in the method-based data-prep, I can't count on knowing all customized properties up front.

1. I could use bogus to generate an object up front, then have the builder overwrite properties

• I can't tell what properties are custom and which are not, which may be weird in cases like reference ids.

2. Fill unset properties before generating

• requires extra effort, but clarifies existing values
• simplifies cases where we start with a provided object

3. Modify generation rules instead of modifying an object

• more complex, but clearer usage for generating many objects
• can easily lean on bogus default type rules

If I pursue choice 2, here are ways to fill values
https://stackoverflow.com/questions/26156577/is-there-a-jquery-extend-in-c
https://github.com/omuleanu/ValueInjecter
null sub in automapper: http://docs.automapper.org/en/stable/Null-substitution.html
conditional mapping http://docs.automapper.org/en/stable/Conditional-mapping.html
Q: can I handle all properties in one go? using a condition for == default(T)?

from testingpatterns.

I'm realizing that bogus does most of the things I'm concluding i should do with my builder

• update rules and defer generation until last moment
• populate existing items from rule set
• generate one or many based on same rules

It even allows named rule sets, but they are based on string keys : /. Too magical

What it doesn't provide well are terse customization and named scenarios per type. It also doesn't play well with having persistence or other configuration injected.
This leaves me with

1. Stick mostly to current 1-call preps that wrap bogus scenarios (still argument heavy)
2. Inherit from bogus and modify my dataprep to pump out configured instances with getters
   • this could get a little weird. What would I be injecting into other preps? an instance doesn't work, it needs to be a fresh instance on every call. I could use ninject/DI to automate something like that.
3. Inherit from bogus and have a 'factory' class that just delivers configured instances

from testingpatterns.

Here is a possible example in Bogus https://github.com/bchavez/Bogus/blob/master/Source/Bogus/Faker%5BT%5D.cs

from testingpatterns.