Non-Primitives built as null

Hi,

In the absence of being able to submit an email using the nbuilder.org
contact page at http://www.nbuilder.org/Contact due to a Runtime Error that
occurs, I am raising my question as an issue.

Here is the email I attempted to submit...

Hi Gareth,

I'm currently evaluating NBuilder for use at my place of work in order to
replace my own feeble attempt at creating a data builder for use in our
unit tests.

I really like what I see from the examples on your site and am looking
forward to testing it out.

However, I do have one question that I haven't seen answered in the
documentation.

My question has to do with a difference between your implementation and
mine which has left me wondering if my implementation is not using best
practices or whether I should make a feature request/create a patch.

The best way to explain myself is with a code sample...

public class MyClass1
{
    public MyClass2 Property1 { get; set; }
    public int Id { get; set; }
}

When I use NBuilder to create an object of MyClass1, Property1...which is
not a primitive type...is created as null.

In the test data builder that I created, I have my builder call builders
for each of the non-primitive types so that they are not null. My reasons
for doing so is that it allows me to create an object which I only need to
specify the properties I care about.

In the example above I would need to create MyClass1 as follows:

var myObject = Builder<MyClass1>
                         .CreateNew()
                         .With(p => p.Property1 =
Builder<MyClass2>.CreateNew().Build())
                         .With(p => p.Id = 150)
                         .Build();

Since I frequently need to create classes that have many such properties it
seems like noise when used in a test that only requires (in this example)
that the Id be 150.

Is there any way for me to configure NBuilder to automatically build all of
the non-primitive types as well? If not, is there any reason why NBuilder
should not include such a feature? If this is against the best practices of
builder classes I'd be eager to learn so that I can correct my implementation.

If it can be a new feature, I'd be happy to make an attempt at creating a
patch.

Thanks in advance,
Josh

Original issue reported on code.google.com by joshuajr...@gmail.com on 5 Jan 2010 at 10:21

Hi Josh

Sorry you had problems with the contact form.

You can do this by inheriting from SequentialPropertyNamer and overriding the 
method
HandleUnknownType().

Then you must set your new property namer using
BuilderSetup.SetDefaultPropertyNamer(myPropertyNamer) or
BuilderSetup.SetPropertyNamerFor<Product>(myTypeSpecificPropertyNamer)

You can see an example of this if you download or browse the source code and 
look in
the functional tests project under 'Extensibility/ExtensibilityTests.cs'

I have plans for a better way of doing this which is going to be similar to the 
way
the 'ExtensibleRandomValuePropertyNamer' works, which was contributed by Tim 
Scott
but for the time being, hopefully this information will help you out.

Let me know if any probs or I haven't answered your question properly.

Gareth

Original comment by garethdo...@googlemail.com on 12 Jan 2010 at 11:55

Changed state: Fixed
Added labels: Type-Other
Removed labels: Type-Defect

asiftasleem / nbuilder

Non-Primitives built as null #35