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.

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.

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.

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!

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.

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.

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.

A question that frequently rises when building enterprise applications is: “Where should we compose object graphs?” and the answer is given by the Composition Root pattern: “As close as possible to the applications entry point.”

The Composition Root pattern is described in the excellent book, Dependency Injection in .NET by Mark Seemann.

Here is the definition from the book:

A Composition Root is a (preferably) unique location in an application where modules are composed together.

When working with the Enterprise Library, it is very common to hide the complexities of initial context creation by using the built-in IServiceLocator implementation provided by the EnterpriseLibraryContainer class.

Since I completely agree with the statement “Service Locator is an Anti-Pattern” I would like to compose all Enterprise Library modules in the Composition Root. Then, I can use well-known DI patterns (such as Constructor Injection) to supply the Dependencies.

Fortunately, the EnterpriseLibraryContainer class contains a method named “ConfigureContainer” that reads the current configuration and supplies the corresponding type information to configure a dependency injection container (by default Unity).

After, configuring the container in the Composition Root we can resolve any instance of a type from Enterprise Library as with any other object.

1. Create db tables

We’ll create 3 tables, one for the messages (MESSAGE), one for the supported locales (SUPPORTEDLOCALE) and one for the web applications that need localized messages (INTERNALAPPLICATION). The Message table should have columns for id, application name, locale (foreign key - the id of locale table), message key and message value. The SupportedLocale table should have columns for id, locale and locale description. Finally the InternalApplication (INTERNALAPPLICATION) table should have columns for id, application name and locale (foreign key - the id of locale table).

2. Create POJOs

Create 3 classes with attributes mapped by the table columns.

3. Create dao and hibernate mapping

Create 2 methods – one for retrieving locales (select * from locale) and one for retrieving messages taking as parameter the locale string (select m from Message m join m.supportedLocale sl where sl.locale=?).

Create messages.hbm.xml file for the mapping.

4. Create service

Create 2 methods that each call the appropriate dao method and return transfer objects as a result.

5. Create message provider class

Create a class that extends HashMap and override method get(Object key).

Call the service method to retrieve all locales and for each supported locale create a map that contains the locale string and a map with the key and value (e.g. localeMaps = new HashMap<locale, Map<key, value>>();). Next, call the service method passing the locale as parameter to retrieve the messages and add the key and the value to the map.

Finally, find the current locale of the application and get the corresponding key.

FacesContext context = FacesContext.getCurrentInstance();
String applicationLocale = context.getViewRoot().getLocale().getLanguage();

value = localeMaps.get(applicationLocale).get(key);

In faces-config.xml define a managed bean with name the resource bundle var and ‘application’ scope and that’s it!!

Solution: Better educate all professionals playing a role in the new architecture or – even better – have them participate in pilot implementations of the new architecture.

Our initial thoughts were pretty much pessimistic, with doubtful merges and lots of manual work. Fortunately the following worked without any problem:

Create two working directories:

• the master one, linked to the internal svn repository. All development takes place in that working directory. Assume that the connect string is something like svn+ssh://user@server/svn/repo1. If necessary do a checkout from that repository: svn co svn+ssh://user@server/svn/repo1
• the client one, linked to the client’s svn repository. Assume that the connect string is something like svn+ssh://clientUser@clientServer/var/svn/clientRepo1. Perform a checkout the first time to make sure the repository location is properly set: svn co svn+shh://clientUser@clientServer/var/svn/clientRepo1

At the end of an iteration, commit all the changes from developers working on this iteration. It is assumed that this would be the version delivered to the client for further testing.

Now move to the client’s directory and perform an export from the internal repository, using the following operation: svn exp svn+ssh://user@server/svn/repo1. That will bring the latest version of the internal repository to the working directory linked to the client repository. Then, just by performing a simple check in we update the client’s repository with the latest change: svn ci.

The above process works well only in case the client is not performing changes to the repository simultaneously with your team!If this is not the case, more work is required to get those changes back to the master repository!

It may also be used for occasional snapshots of the master repository to guarantee against its potential failures.

There are many cache providers, among them is EhCache which we will be using in this example. In order to get second-level cache to work, first we have to tell hibernate about it. Add this in the hibernate configuration file (hibernate.cfg.xml):

<property name="cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
<property name="cache.use_query_cache">true</property>
<property name="cache.use_second_level_cache">true</property>

<ehcache>
<diskStore path="java.io.tmpdir"/>

<defaultCache
maxElementsInMemory="20000"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="300"
overflowToDisk="true"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="300"
memoryStoreEvictionPolicy="LRU" />

<cache name="com.app.entities.City"
maxElementsInMemory="15000"
eternal="true"
overflowToDisk="false" />
...
</ehcache>

@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE)
public class City {
private Long id;
private String name;
....
}

public List<City> findPopularCitiesByCountryId(Long countryId) {
List<City> cities = session.createQuery("FROM City AS c WHERE
c.country.id=? ORDER BY c.popularity DESC")
.setCacheable(true)
.setLong(0, countryId)
.setMaxResults(20)
.list();
return cities;
}

[net.sf.ehcache.Cache]-[DEBUG] org.hibernate.cache.StandardQueryCache cache - Miss
[org.hibernate.cache.StandardQueryCache]-[DEBUG] query results were not found in cache

[org.hibernate.cache.ReadWriteCache]-[DEBUG] Cache miss: com.app.entities.City#1412
[org.hibernate.event.def.DefaultLoadEventListener]-[DEBUG] object not resolved in any cache

[net.sf.ehcache.Cache]-[DEBUG] org.hibernate.cache.UpdateTimestampsCache cache - Miss
[org.hibernate.cache.EhCache]-[DEBUG] Element for cities is null

[org.hibernate.cache.ReadWriteCache]-[DEBUG] Cache lookup: com.app.entities.City#1412
[org.hibernate.cache.ReadWriteCache]-[DEBUG] Cache hit: com.app.entities.City#1412