It is now possible to create an anonymous variable for Uri as with any other common type:
By default, both the scheme name and the authority part are obtained from the context. A custom UriScheme class represents the URI scheme name while the authority part is an anonymous variable of type string.
Example URIs along with their component parts can be found here. Since both parts are received from the context, they can be easily customized.
Supplying a custom scheme name
The UriScheme type provides by default the name "scheme". However, by injecting a specific instance of this type we can easily override it with something else (e.g. "http").
Supplying a custom authority
This is preferred only when each test constructs its own instance of the Fixture type since this change will apply for all the strings received from the context.
Since the authority part is a string received from the context, it is possible to modify the base of all strings and get the desired name for the authority.
Supplying a custom Uri
As with any other generated specimen, it is possible to completely take over it's creation. Using a custom ISpecimenBuilder type, each time a Uri is requested, a predefined Uri will be returned.
An automatically published release created from the latest successful build can be downloaded from here. The latest version is also live on NuGet.
In this post I will discuss a possible solution for having Castle Windsor resolving types for both MVC controllers and Web API controllers. Since the former is well known I will focus mostly on the Web API part.
A team building a mobile web application uses the ASP.NET MVC stack combined with another web services framework. With the release of the Beta version of ASP.NET MVC 4 they decided to give Web API a try (side by side with MVC controllers) and see if it fits their needs.
Be careful as there are more than one DependencyResolver types. One defined in System.Web.Mvc namespace and one defined in System.Web.Http namespace. We need the latter here.
Once we define the delegates and set a breakpoint we can see what types the framework requests.
At first an instance of the IHttpControllerFactory type is requested:
Followed by a request for an instance of the ILogger type and so on.
The first thing we want to do is to create a type implementing the IHttpControllerFactory interface.
Note that inside the WindsorHttpControllerFactory class the CreateController method takes a string for the name of the controller. That means we need to use the Windsor's Named method to set a name for each controller registration. (We can also trim the "Controller" part from the name and also pluralize the remaining part.)
Let's also create a NullLogger implementing the ILogger interface.
For all the other instances that the framework requests there are default implementations in the System.Web.* assemblies and we can now create a Windsor Installer to encapsulate the registration logic.
In the Application_Start method we add the installer and set the delegates for the SetResolver method. That way when the framework requests an IHttpControllerFactory instance, Windsor will supply the one we created earlier.
In order to have Windsor resolve regular controllers (side by side) we can create and add another installer as well as an implementation of the IControllerFactory interface.
Finally, a gist with all the source code can be found here.
From version 2.9.0 of AutoFixture, the Likeness class contains a new feature for creating a dynamic proxy that overrides Equals on the destination type.
As an example, we want to compare instances of the following types:
We can have the following syntax (prior to version 2.9.0):
However, from version 2.9.0 there is also a new CreateProxy method on Likeness which returns a proxy of the destination type overriding Equals with Likeness's instance of IEqualityComparer (the SemanticComparer class):
Below is also an example, where we need to verify that an expectation was met:
Although the new Bar instance is created inside the DoSomething method, we can pass a proxied Bar instance on the mock's Verify method.
Internally, a custom Proxy Generator was written which also supports types with non-parameterless constructors. In order to create proxies of such types, the values from the source have to be compatible with the parameters on the destination constructor. (The mapping between the two is made possible by using the same semantic heuristics, as the default semantic comparison.)
Starting with version 2.6.0, when this attribute is applied on a data field AutoFixture will try to generate a value that matches the specified regular expression.
Let's take as an example the following type:
Prior to version 2.6.0 if we request an anonymous instance from AutoFixture, by default we would get back an instance of the above type with it's properties containing values similar to those below.
However, from version 2.6.0 AutoFixture can handle requests with regular expressions, through the RegularExpressionAttribute class, by issuing a new request for the specified regular expression pattern.