Combining Data Theories in AutoFixture.Xunit extension

Crossposted from my personal blog.

xUnit.net supports parameterized tests via data theories which are types deriving from the Xunit.Extensions.DataAttribute type. Some popular attributes include:

InlineDataAttribute, PropertyDataAttribute and ClassDataAttribute.

AutoFixture.Xunit extension includes a very useful type, for providing auto-data theories, called AutoMoqDataAttribute

Imagine a Scenario where we have a unit test method with 3 parameters. We want the first parameters to be supplied by InlineData and the rest by AutoFixture using AutoMoqData.

This is now possible using the InlineAutoDataAttribute type which is now on the trunk and will be available on next public release (after version 2.1). It provides a data source for a data theory, with the data coming from inline values combined with auto-generated data specimens generated by AutoFixture.

InlineAutoDataAttribute derives from CompositeDataAttribute, an implementation of DataAttribute that composes other DataAttribute instances.

Here is how it works:

  • Delegate the GetData method call to the first attribute.
  • Loop through the results from the first attribute and check if the length of each object array matches the number of arguments required by the method.
    • If so, yield the object array.
    • If not, invoke GetData on the next attribute.
      • Throw away the first objects from the result in order to continue from where it ran out of objects from the first result set and concatenate the rest to the previous array.
  • Recursively repeat this process until all object arrays have the required length.

While this feature comes with AutoFixture.Xunit extension, the CompositeDataAttribute class depends only on the xunit.extensions assembly.

You may compile the code from the latest trunk version, alternatively the latest build (including strong names) can be downloaded from here.

Heuristics for Static Factory Methods in AutoFixture

Crossposted from my personal blog.

Here is a type with a private constructor:

In order to create an instance of that type we have to call one of it’s static factory methods, for example:

If we try to create an Anonymous Variable with AutoFixture right now (version 2.1) it will throw an exception since there are no public constructors:

Using the latest version from trunk (and on the next public release) the above code will work. It will successfully return an instance of the type by using a set of heuristics that enable AutoFixture to search for static factory methods.

The latest build (including strong names) can be downloaded from here.

Enabling Add-In functionality in ASP.NET MVC 3 (Part 2)

Crossposted from my personal blog.

In this post I discussed the implementation of a Unity-specific controller factory  that could take a delegate as a parameter in the constructor acting as the fallback factory when the DI container can not supply a controller.

However, I did not really like the initial design. There are cases when the UnityControllerFactory can be used standalone without third party extensiblity in mind.

One possible improvement in the design is to introduce a composite implementation for an IControllerFactory. That way, we still have the chance to supply a MEF-specific controller factory.

A possible implementation of the CreateController method is the one below:

It will iterate through all controller factories calling their CreateController method. The first IController instance provided by the controller factories is returned.

With this implementation, if the Unity-specific controller factory can not provide an IController instance we will ask the next controller factory (MEF-specific controller factory in this example) to provide the IController instance, and so on.

The SetControllerFactory method can accept an instance of a CompositeControllerFactory type as shown below:

ImplementationUnit tests and NuGet Package. Sample application available here.

Does culture matter in outsourcing deals?

In a recent article in Outsource Magazine (http://www.outsourcemagazine.co.uk/articles/item/4051-secret-agreements-on-culture-), Brandi Moore contested the ability of integrating outsourcing with local teams without ‘talking about the cultural differences’ and trying to find solutions.
Esteban Herrera, COO of Horse For Sources Research, rebutted with this article http://www.horsesforsources.com/brandi-esteban.

Reading through both articles one may notice that both agree finally that cultural differences are important in an outsourcing agreement. It’s just that Mrs Moore advocated that most outsourcing providers do not pay attention to it, while Mr Herrera insisted that this is not the case – at least anymore!

Allow me to add here that training (at least 3 weeks preached Mr Herrera) is not something that changes the culture of a person! It helps him understand other cultures, but acquiring a new culture is a life-long experience!
Ancient Greek philosophers defined ‘Greek‘ as ‘anyone having taken part in the Greek education (παιδεία)‘ which is a lot more than a few weeks training in a closed room!