QuickGenerate : The Competition

As I stated before, the QuickGenerate lib is a side effect from my interest in property based testing.

At the time I could not find anything suitable to fill in for the part of QuickCheck’s Arbitrary class.

So I rolled out my own.

And for me, it does all it that it is supposed to do.
Keep in mind that I’m not using this to populate databases,
Keep in mind that I’m not using this as builders in my unit tests.
I am using it to supply quickdotnetcheck with shrinkable input.

Well, I lied, I do use it to populate databases and all that, … these days.
But the point is, that was not the goal.

A while ago I said to a colleague : ‘If I had known about NBuilder while I was writing QuickNet, QuickGenerate would probably not exist’.
Today I reckon that ain’t true.
I would have run into an issue sooner or later because the goals of both libs are too different.
That applies too all others mentioned below aswell.

NBuilder :
Cool api, mature lib. Probably the easiest one to use. Struggles when used in tests (I think it’s likely that this wasn’t the main focus of the project).

AutoFixture :
Really aimed at simplifying your test code. It offers (amongst a lot of other things such as auto-mocking, f.i.) random data generation in order to implement the test data builder pattern (shines in unit tests).

AutoPoco :
A co-worker of mine recently pointed out this one. It looks really powerfull. And thanks to aforementioned co-worker, who submitted a patch recently, it now has a feature which quickgenerate just can’t produce. Once again, … thank you Jan .

There’s propably others.

I think most, if not all features of ‘the competition’ can also be achieved reasonably painlessly with quickgenerate.
And most, if not all quickgenerator features can also be achieved reasonably painlessly using one of ‘the competition’ libs.

So whichever one you prefer using, depends on your goal.
And on how close that relates to the goals of the respective lib.