AutoPoco

AutoPoco 0.4 released - features features features

Rob Ashton — Thu, 15 Apr 2010 08:19:25 GMT

What's that? I skipped a number? Actually I didn't, but 0.3 wasn't particularly major so making a blog entry seemed a bit redundant :)

What have I added? Glad you asked:

Method Invocation

During configuration, you can now set up data sources for parameters of methods, just pass in raw values or just call a method with no arguments.

It's all been done in a strongly-typed manner to fit in with the rest of AutoPoco.

                x.Include<SimpleMethodClass>()
                    .Invoke(c => c.SetSomething(
                        Use.Source<String, RandomStringSource>(5, 10),
                        Use.Source<String, LastNameSource>()))
                    .Invoke(c => c.DoSomething());

Obviously this needs a brother to override this configuration at the time of object creation, and that looks something like this:

            IList<SimpleMethodClass> items = mSession.List<SimpleMethodClass>(100)
                    .Invoke(x => x.SetSomething("Something"))   
                .Get();

And this will call SetSomething on all the created objects with the argument "Something" - this set of functionality is for those who don't have accessible setters on public properties but still wish to invoke them. The alternative was to start proxying around the objects and demanding that properties be virtual - but unless somebody says otherwise, I think that's a bit heavyweight for this sort of library.

Improved Convention Support

Conventions have been baked into AutoPoco from the start, but weren't fleshed out until this iteration, they can be used to match types of property/field, or match the names of properties/fields (or both) and apply rules to them without any knowledge of the specific type being configured.

This is useful for those with multiple projections of their domain, which follow naming conventions throughout the project.

    public class EmailAddressPropertyConvention : ITypePropertyConvention
    {
        public void Apply(ITypePropertyConventionContext context)
        {
            context.SetSource<EmailAddressSource>();
        }

        public void SpecifyRequirements(ITypeMemberConventionRequirements requirements)
        {
            requirements.Name(x => String.Compare(x, "EmailAddress", true) == 0);
            requirements.Type(x => x == typeof(String));
        }
    }

This convention will match any property of type string called EmailAddress and apply the EmailAddressSource to it.

Inheritance

This was more complicated to deal with, and I expect to be writing a couple of quick blog entries detailing some of the gotchas encountered when writing the code for this, as googling didn't really provide the answers I was looking for (My first port of call for all problems)

The gist of it, is that if you have an interface with a property, and you define a rule for that property, then any class that implements that property will also inherit that rule (the same goes for base classes and their properties).

If a rule is defined for that specific derived class, then it will override the rule provided by the interface or base class. The only thing I haven't expliclty included in this is open generics, because they're a bit more tricky to come up with an elegant solution for.

Consider the following class structure:

    public interface ISimpleInterface
    {
        string InterfaceValue
        {
            get;
            set;
        }

        string OtherInterfaceValue
        {
            get;
            set;
        }
    }

    public class SimpleBaseClass : ISimpleInterface
    {
        public string BaseProperty
        {
            get;
            set;
        }

        public virtual string BaseVirtualProperty
        {
            get;
            set;
        }
    
        public string InterfaceValue
        {
	      set;
          get;
        }
        
        public string OtherInterfaceValue
        {
            get;
            set;
        }
    }

    public class SimpleDerivedClass : SimpleBaseClass, ISimpleInterface
    {
        public string Name
        {
            get;
            set;
        }

        public override string BaseVirtualProperty
        {
            get;
            set;
        }
    }

With the following configuration

                x.Include<ISimpleInterface>()
                    .Setup(c => c.InterfaceValue).Value("InterfaceValue - ISimpleInterface")
                    .Setup(c=>c.OtherInterfaceValue).Value("OtherInterfaceValue - ISimpleInterface");
                 x.Include<SimpleBaseClass>()
                    .Setup(c => c.BaseProperty).Value("BaseProperty - SimpleBaseClass")
                    .Setup(c => c.BaseVirtualProperty).Value("BaseVirtualProperty - SimpleBaseClass");
                x.Include<SimpleDerivedClass>()
                    .Setup(c => c.Name).Value("OtherTest")
                    .Setup(c => c.BaseVirtualProperty).Value("BaseVirtualProperty - SimpleDerivedClass")
                    .Setup(c => c.OtherInterfaceValue).Value("OtherInterfaceValue - SimpleDerivedClass");

Requesting a SimpleBaseClass, we get

BaseProperty: "BaseProperty - SimpleBaseClass"
BaseVirtualProperty: "BaseVirtualProperty - SimpleBaseClass"
InterfaceValue: "InterfaceValue - ISimpleInterface"
OtherInterfaceValue: "OtherInterfaceValue - ISimpleInterface"

Requesting a SimpleDerivedClass, we get

BaseProperty: "BaseProperty - SimpleBaseClass"
BaseVirtualProperty: "BaseVirtualProperty - SimpleDerivedClass"
InterfaceValue: "InterfaceValue - ISimpleInterface"
OtherInterfaceValue: "OtherInterfaceValue - SimpleDerivedClass"

It looks a bit complicated up front, but it makes sense if you think about it and that's what matters (the functionality is there if you need it, if you don't need it then you don't need to worry about it).

More data sources

I was expecting to have to do these myself, along with a load of standard property/field conventions - but I had an e-mail from Khalid Abuhakme letting me know he'd created a fork with some standard data sources in them.

I have pulled them through and now our list of data sources looks something like this:

ColorSource
CountrySource
CreditCardSource
DataOfBirthSource
EmailAddressSource
EnumerableSource<T> where T : IDataSource (Really cool addition Khalid!)
FirstNameSource
LastNameSource
LorumIpsumSource
RandomStringSource
UsStatesSource

We'll end up with a lot more of these for sure, and still need a more customisable aspect to some of the default ones, but if anybody else wants to contribute then feel free, as adding conventions and data sources is what will make AutoPoco really useful.

Why diversity and choice are good things

Rob Ashton — Fri, 09 Apr 2010 20:37:47 GMT

I noticed a bit of traffic coming from somewhere I didn't recognise, so I went over to check it out...

It was just ranty link bait so I won't bother linking it, but it reminded me of a stance I took a few years ago while I was still just using the MS provided frameworks and software like a good little drone...

Starting with the obvious - "We already have NBuilder and AutoFixture so what on earth do we need another one of these for? "

When I set out to write AutoPoco, the fact that there were existing projects wasn't even a consideration for me, I wanted a weekend project which combined convention with configuration and exposed a tidy fluent interface in a manner in which I'd like to use it.

Open sourcing it just made sense because there is no point in keeping things locked away where other people can't see or learn from them (or even give feedback so I can carry on learning...)

That aside, it turned out that my desire for convention over configuration, and my overwhelming desire to keep configuration to a minimum whilst generating meaningful test data was a radically different approach (imo) to those existing projects, so I've decided to carry on pushing down that route to see where it takes me.

Could you not have just forked an existing project?

Sure, but then I'd have had even more work to do because the existing projects would have been hard to shoe-horn the convention/configuration aspects into without either wrapping the entire system or re-writing entire aspects of it.

Approaching a problem in your own way can often lead to alternative solutions and in building alternative solutions and open sourcing them, I see can see no ill effects, only positive ones whereby we all win because we're putting more ideas into the mix.

But why do what has been done before?

Seriously? This is the kind of mindset that can really irk me at times - without re-takes on existing ideas we wouldn't have any competition, we'd lose a lot of growth in the open source (and closed source) arenas and I dare say we'd all just be working on the frameworks that Microsoft give us because they solve all the problems - right?... right?

Why write StructureMap if we already have Castle/Unity/etc? (I don't actually know which came first hah)
Why do a clone of Hibernate when we already have Entity Framework/Linq2Sql etc?
Why create OpenRasta when we have WCF and MS MVC?
Why create StackOverflow when Experts Exchange already exists? [stretching it a bit here]
Etc?

Because they solve the problems in different ways, because some people don't like the way the existing frameworks work and want something that suits their workflow better, because learning from other people's mistakes means we don't have to carry around the legacy baggage that backwards compatability on some mature software projects can force on us.

Couldn't you have found another problem to solve?

I find this question to be confusing - I spend my working hours and most of my spare time leading the development of a product that is pretty much guaranteed be used by some fairly large PLCs once it has been released, I solve new problems every day and the joy of sitting down with a codebase like AutoPoco is I get to play around with no commercial pressure or expecations and put into practise the things I have learned whilst making something that I consider to be quite pretty.

The enjoyment of such a thing is in writing it and thinking about it - in crafting something I want to use, not in releasing it and not in getting other people to use it (Why I would I even try?) - but to be able to put a small piece of code out and to foster discussion on the pros and cons of the different approaches I have used or could be used with an active and growing community.

One of the most enjoyable things I ever do in our product is to replace home-grown code with other people's open source efforts so I'm hardly guilty of the crime of doing everything myself - and we may well end up using one of the existing object generation frameworks rather than AutoPoco if they do more of what we want (unlikely).

Basically...

If you don't like it, then don't use it, and if nobody likes it and nobody uses it then it was still fun to write and nobody lost anything through the actions of a whimsical software developer.

But... If you do like it, and you do use it, or if other people use it or if other people learn from it, or get ideas from it, or use it as the inspiration for their own take on the problem space then collectively we've all gained something because somebody somewhere is going to be learning something.

And that is what OSS is about, it's not about getting free software, it's about having the choice to use what you want, and to find out how other people have gone about solving problems and to learn from where other people have tread before.

Me? I'm enjoying the development of AutoPoco and think there is enough of a difference between it and existing frameworks to justify to myself in the continued development of it. I want my conventions, and I want my automatic set up, and I want to be able to generate a craptastic amount of realistic test data for my systems as well as using it for the day to day unit tests I litter about the place.

And that's good enough for me.

AutoPoco v0.2 Released

Rob Ashton — Thu, 08 Apr 2010 00:48:41 GMT

I've added some features to AutoPoco to make it actually functional

Configuration can now be done automatically:

IGenerationSessionFactory factory = AutoPocoContainer.Configure(x =>
{
    x.Conventions(c =>
    {
        c.UseDefaultConventions();
    });
    x.AddFromAssemblyContainingType<SimpleUser>();
});

As to start with, meaningful data isn't always required - just non-nulls and sensible defaults.

Collections can now be created with controlled content, for example:

            mSession.List<SimpleUser>()
                .Random(5)
                    .Impose(x => x.FirstName, "Bob")
                .Next(5)
                    .Impose(x => x.FirstName, "Alice")
                .All()
                .First(5)
                    .Impose(x => x.LastName, "Blue")
                .Next(5)
                    .Impose(x => x.FirstName, "Red")
                .All()
                .Get();

Will create a table of data looking something like:

#	First Name	Last Name
0	Bob	Blue
1	Alice	Blue
2	Alice	Blue
3	Bob	Blue
4	Bob	Blue
5	Alice	Red
6	Bob	Red
7	Alice	Red
8	Bob	Red
9	Alice	Red

Obviously these simple examples are only the beginning, I've also written some documentation for the existing features + new features over at the codeplex site:

I'll be using AutoPoco to generate a ridiculous amount of test data for one of our systems in the coming weeks, so I'll no doubt discover any shortcomings and rectify them, in the mean-time feel free to ask for things in the discussons forum at the Codeplex site (or in the comments here)

AutoPoco v0.1 Released

Rob Ashton — Tue, 06 Apr 2010 07:54:39 GMT

** Update: Version 0.2 Now Released**

The product of one weekend and a bank holiday's code, I wanted to simplify the way we were generating test data for our tests, and writing a class called <ObjectName>Builder with lots of permutations for overriding various properties for every single object I wanted to generate was getting tedious.

I also wanted to have a go at writing something that exposed a fluent interface that could be extended using extension methods, and combined convention with configuration to do its job in an easily configurable fashion.

Combining these two into a project was a fun thing to do, whether the project is of any use to anybody else is irrelevant, but you don't know unless you push these things out...

http://autopoco.codeplex.com

Using it should be self explanatory, but here is a quick overview of what AutoPoco attempts to achieve.

Configuring a factory
A factory can be created once and then re-used by tests (if you so wish), a factory is just a configured instance of AutoPoco and has therefore performed some of the more expensive reflection operations ahead of use.

Using the default conventions, any recognised properties on an object will automatically be populated with an instance of that property type, and this will obviously recurse down the object graph.

var factory = AutoPocoContainer.Configure(x =>
            {
                x.Conventions(c =>
                {
                    // Map all public properties + fields
                    // Ensure  we don't end up with nulls
                    c.UseDefaultConventions();
                });

                // Include the simple user type
                x.Include<SimpleUser>()
                    // Expicitly set data sources for its properties
                    .Setup(c => c.EmailAddress).Use<EmailAddressSource>()
                    .Setup(c => c.FirstName).Use<FirstNameSource>()
                    .Setup(c => c.LastName).Use<LastNameSource>();

                // Include the user role type (used by User.Role)
                // Set the name as a string with a length between 5 and 10
                // Note: Random is an extension method and only gets provided if the property/field is a string
                x.Include<SimpleUserRole>()
                    .Setup(c => c.Name).Random(5, 10);

                // Include these types, but use the default conventions to auto-set properties/fields
                x.Include<SimpleFieldClass>();
                x.Include<SimplePropertyClass>();
                x.Include<DefaultPropertyClass>();
                x.Include<DefaultFieldClass>();
            });

Creating a session
A session should be created once per test (or more), and will use data sources scoped to that session to populate requested objects. An example of this would be a source configured to create unique ids for "database" objects - each id would be unique across that session, but creating another session would mean that session had its own data source back at the original state.
Don't worry, you don't need to understand this, it's just there for those that want it.

var session = factory.CreateSession();

Creating Objects
This is the important bit - any number of objects should capable of being be created from the session, with the ability to easily override any of the properties on those objects

            // Get a single default user
            // User.Role will be set automatically by AutoPoco
            // User.EmailAddress will be a valid e-mail address
            SimpleUser singleDefaultUser = mSession.With<SimpleUser>().Get();
            
            // Get 100 users
            // They all have different e-mail address
            // They all have different first names
            // They all have different last names
            SimpleUser[] users = mSession.With<SimpleUser>().Get(100);
            
            // Create a role
            SimpleUserRole sharedRole = mSession.With<SimpleUserRole>().Get();
            
            // Impose that role on 100 users
            // Those 100 users still have different e-mail addresses etc etc
            SimpleUser[] usersSharingRole = mSession.With<SimpleUser>()
                .Impose(x => x.Role, sharedRole)
                .Get(100);

I think this is quite neat and tidy, although there are lots of features missing (ability to populate collections, a convention to deal with enums, a convention to deal with inheritance - and lots of extension methods to allow the easy manual configuration of all of those things.

I'll add them as I need them or as they are requested. This is my framework for my use, but you're all welcome to use and contribute to it too.