I first learned about AutoPoco from this blog post by Scott Hanselman. But it wasn’t until earlier this spring that I had an opportunity to use it. I’d started a new job at the end of March, and in the process of getting familiar with the code base on my first project, I came across the code they used to generate test data. I used AutoPoco to generate a much larger set of realistic-looking test data than was previously available.
Last week, I gave a presentation to my local .NET user group (RockNUG) on the framework. The slide deck I put together is available here, and there’s some demo code here. The rest of this blog post will speak to the following question (or a rather rough paraphrase of it) that came up during a demo: is it possible to generate instances of a class with an attribute that has a wide range of values, save one?
The demo that prompted this question is in the AddressTest.cs class in the demo code I linked to earlier. In that class, the second test (Generate100InstanceOfAddressWithImpose) gives 50 of the 100 addresses a zip code of 20905 and a state of Maryland. The possible objective of the question could be to generate a set of data with every state except one.
After taking a closer look at the documentation, and a review of the AutoPoco source code for generating random states, I came up with an answer. The Generate1000InstancesOfAddressWithNoneInMaryland test not only excludes Maryland from the state property, it uses abbreviations instead of the full state name. The implementation of CustomUsStatesSource.Next adds a couple of loops (one if abbreviations are used, one if not) that keep generating random indexes if the resulting state is contained in the list of states to exclude.
The ability to pass parameters to custom datasources in order to control what type of test data is generated is an incredibly useful feature. In the work I did on my project’s test generator, I used the capability in order to create a base datasource that generated numeric strings with the length controlled by parameters. This allow me to implement new datasources for custom ids in the application by inheriting from the base and specifying those parameters in the constructor.
Because AutoPoco is open source, if your project has specific needs, you can simply fork it and customize as you wish. Another value-add of a framework like this could be realized if you write multiple applications that share data. In such a scenario, test data becomes a corporate resource, with different sets generated and made available according to the scenarios being tested.
Another advantage of AutoPoco for test generation is that its use of plain old CLR objects keeps it independent of specific database technologies. I’m currently using AutoPoco with RavenDB; it will work just as well with the database technology (or ORM) of your choosing–Entity Framework, NHibernate, SQL Server, Oracle, etc.
AutoPoco is available via NuGet, so it’s very easy to add to whatever test assemblies you’ve currently got in your solutions. As long as you have public, no-arg constructors for the CLR objects (since AutoPoco uses reflection to work), you can generate large volumes of realistic-looking test data in virtually no time.