Author Archives: nbaxevanis

Combining Data Theories in AutoFixture.Xunit extension

Posted on by
Reply

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

Posted on by
Reply

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)

Posted on by
Reply

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:

Implementation, Unit tests and NuGet Package. Sample application available here.

Enabling Add-In functionality in ASP.NET MVC 3

Posted on by
Reply

Crossposted from my personal blog.

Update:  Part 2

I remember, back in 2006 when I wrote my first managed add-in for AutoCAD. The fact that we could extend the functionality of a very big product, using .NET was huge. Till that time, if we wanted to use .NET for add-in functionality we had to rely on RCW or else we had to write messy and error-prone VBA code. 

Today, anyone who builds applications in managed code (using .NET 4 and above) has built-in functionality for extensibility provided by the framework itself. In this post, we will be extending an ASP.NET MVC 3 application. We are going to use Unity as the Dependency Injection (DI) container and the types from the System.ComponentModel.Composition namespace (or else, MEF) for managing the composition of parts.

The host application, is the one shown below. I have selected the interesting types that I will be discussing.

HostSolutionTree

DiscoverableControllerFactory

A MEF-specific DefaultControllerFactory derived type. It gets the exported types with the contract name, derived from an IController type. After the controller is supplied, the MVC framework will resolve the Views.

UnityControllerFactory

A Unity-specific DefaultControllerFactory  derived type. There are many implementations around. The difference from other implementations is that this one takes a delegate as a parameter in the constructor that acts as the fallback factory when the DI container can not supply a controller. This is a very important part of our architecture because here we have the chance to supply the target controller (as an add-in) using MEF.

Global.asax

Here we specify the default path for the extensions. We create a new instance of the DiscoverableControllerFactory class passing a CompositionContainer and a DirectoryCatalog. Keep in mind that the DirectoryCatalog is one of the many choices that MEF provides for discovering parts. Besides the creation of the DiscoverableControllerFactory we also create a new instance of the UnityControllerFactory class acting as the default controller factory. Any controllers that this factory can not supply will fallback to the DiscoverableControllerFactory using it’s CreateController method. One last thing to note, this is the application’s Composition Root. The DI container is referenced here, where the composition happens, and nowhere else in the entire application.

The add-in application is a regular class library and it’s structure is shown below. I have selected the interesting types that I will be discussing.

AddInSolutionTree

ConceptController

This is a proof of concept Controller for this demo. It is decorated with the ExportAttribute and ExportMetadataAttribute. The later is needed in order to help the DiscoverableControllerFactory to choose the right controller among all the controllers supplied by this and other add-ins. The PartCreationPolicyAttribute is needed in order to specify that a new non-shared (transient) instance will be created for each request.

Index.cshtml, Web.config

Nothing special to say here. The razor view is just any other (razor) view. The Web.config is needed as a hint for the MVC framework to compile the razor views at runtime.

Make sure to select all the views and set the property “Copy to Output directory” to “Copy if newer”. This is important because each time we compile the add-in library besides the .dll with the models and the controllers we also want the views to be copied there (they are also part of the add-in).

You can download the demo application here. Upon build the Concepts.dll along with it’s Views will be copied in the Web project’s “Extensions” directory. When run, the application will automatically load the assembly the first time the “Concepts” tab is pressed.