AutoFixture as an auto-mocking container

Thursday, 19 August 2010 19:25:50 UTC

The new internal architecture of AutoFixture 2.0 enables some interesting features. One of these is that it becomes easy to extend AutoFixture to become an auto-mocking container.

Since I personally use Moq, the AutoFixture 2.0 .zip file includes a new assembly called Ploeh.AutoFixture.AutoMoq that includes an auto-mocking extension that uses Moq for Test Doubles.

Please note that AutoFixture in itself has no dependency on Moq. If you don't want to use Moq, you can just ignore the Ploeh.AutoFixture.AutoMoq assembly.

Auto-mocking with AutoFixture does not have to use Moq. Although it only ships with Moq support, it is possible to write an auto-mocking extension for a different dynamic mock library.

To use it, you must first add a reference to Ploeh.AutoFixture.AutoMoq. You can now create your Fixture instance like this:

var fixture = new Fixture()
    .Customize(new AutoMoqCustomization());

What this does is that it adds a fallback mechanism to the fixture. If a type falls through the normal engine without being handled, the auto-mocking extension will check whether it is a request for an interface or abstract class. If this is so, it will relay the request to a request for a Mock of the same type.

A different part of the extension handles requests for Mocks, which ensures that the Mock will be created and returned.

Splitting up auto-mocking into a relay and a creational strategy for Mock objects proper also means that we can directly request a Mock if we would like that. Even better, we can use the built-in Freeze support to freeze a Mock, and it will also automatically freeze the auto-mocked instance as well (because the relay will ask for a Mock that turns out to be frozen).

Returning to the original frozen pizza example, we can now rewrite it like this:

[Fact]
public void AddWillPipeMapCorrectly()
{
    // Fixture setup
    var fixture = new Fixture()
        .Customize(new AutoMoqCustomization());
 
    var basket = fixture.Freeze<Basket>();
    var mapMock = fixture.Freeze<Mock<IPizzaMap>>();
 
    var pizza = fixture.CreateAnonymous<PizzaPresenter>();
 
    var sut = fixture.CreateAnonymous<BasketPresenter>();
    // Exercise system
    sut.Add(pizza);
    // Verify outcome
    mapMock.Verify(m => m.Pipe(pizza, basket.Add));
    // Teardown
}

Notice that we can simply freeze Mock<IPizzaMap> which also automatically freeze the IPizzaMap instance as well. When we later create the SUT by requesting an anonymous BasketPresenter, IPizzaMap is already frozen in the fixture, so the correct instance will be injected into the SUT.

This is similar to the behavior of the custom FreezeMoq extension method I previously described, but now this feature is baked in.


Comments

How would you compare and contrast AutoFixture with UnityAutoMockContainer? I started using UnityAutoMockContainer and have been very pleased with it so far. The main contribution it makes is that it reduces the friction of TDD by mocking all dependencies so I do not have to. Then I can extract them using syntax like this

Mock<IFoo> mockFoo = _container.GetMock<IFoo>();


It appears that both AutoFixture and UnityAutoMocker can be used in a similar fashion. Though it appears that AutoFixture has a broader feature set (the ability to create anonymous value types.) Whereas, one can create anonymous reference types by simply asking theUnityAutoMockContainer to resolve the interface or concrete type.

I have only been using UnityAutoMockContainer for a week or two. So when I stumbled upon your most excellent book Dependency Injection in .Net, I discovered AutoFixture and was considering whether to use it instead. I welcome your perspective. By the way, that book on DI you are writing is great! Nice work.

2010-09-09 10:34 UTC
Hi David

Thanks for writing.

As a disclaimer I should add that I have no experience with UnityAutoMockContainer, but that I'm quite familiar with Unity itself, as well as the general concept of an auto-mocking container, which (IIRC) is something that predates Unity. At the very least there are many auto-mocking containers available, and you can often easily extend an existing DI Container to add auto-mocking capabilities (see e.g. this simplified example).

This is more or less also the case with AutoFixture. It started out as something completely different (namely as a Test Data Builder) and then evolved. At a time it became natural to also add auto-mocking capabilities to it.

You could say that the same is the case with Unity: it's a DI Container and was never envisioned as an auto-mocking container. However, since Unity is extensible, it is possible to add auto-mocking to it as well (just as the Autofac example above).

This means that UnityAutoMockContainer and AutoFixture approach the concept of auto-mocking from two different directions. I can't really compare their auto-mocking capabilities as I don't know UnityAutoMockContainer well enough, but I can offer this on a more general level:

AutoFixture shares a lot of similarities with DI Containers (Unity included). It supports auto-wiring and it can be configured to create instances in lots of interesting ways. However, since the focus is different, it does some things better and some things not as well as a DI Container.

AutoFixture has more appropriate handling of primitive types. Normally a DI Container is not going to serve you a sequence of unique strings or numbers, whereas AutoFixture does. This was really the original idea that started it all.

Most DI Containers are not going to try to populate writable properties, but AutoFixture does.

AutoFixture also has a more granular concept of what constitutes a request. For all DI Containers I know, a request to resolve something is always based on a Type. AutoFixture, on the other hand, enable us to make arbitrary requests, which means that we can treat a request for a ParameterInfo differently than a request for a PropertyInfo (or a Type) even if they share the same Type. This sometimes comes in handy.

On the other hand AutoFixture is weaker when it comes to lifetime management. A Fixture is never expected to exist for more than a single test case, so it makes no sense to model any other lifestyle than Transient and Singleton. AutoFixture can do that, but nothing more. It has no Seam for implementing custom lifestyles and it does not offer Per Thread or Per HttpRequest lifestyles. It doesn't have to, because it's not a DI Container.

In short I prefer AutoFixture for TDD because it's a more focused tool than any DI Container. On the other hand it means that there's one more new API to learn, although that's not an issue for me personally :)
2010-09-09 11:04 UTC
Hi Mark,

I just started to play with AutoFixture and its auto-mocking support. As far as I can see, the auto-mocking extensions return mocks without functionality, especially, without any data in the properties.
Example:
var anonymousParent = fixture.CreateAnonymous<ComplexParent>();
This example from the cheat sheet would return a filled fixture:
ComplexParent:
-Child: ComplexChild
--Name: string: "namef70b67ff-05d3-4498-95c9-de74e1aa0c3c"
--Number: int: 1


When using the AutoMoqCustomization with an interface IComplexParent with one property Child: ComplexChild, the result is strange:
1) Child is of type ComplexChildProxySomeGuid, i.e. it is mocked, although it is a concrete class
2) Child.Number is 0
3) Child.Name is null


I think this is inconsistent. Is it a bug or intentional? If it is intentional, could you please explain?

Thanks,

Daniel
2011-09-08 09:57 UTC
Yes, this is mostly intentional - mostly because even if AutoFixture would attempt to assign data to properties, you wouldn't get any result out of it. As an illustration, try using Moq without AutoFixture to create a new instance of IComplexParent and assign a property to it. It's not going to remember the property value!

This is, in my opinion, the correct design choice made by the Moq designers: an interface specifies only the shape of members - not behavior.

However, with Moq, you can turn on 'normal' property behavior by invoking the SetupAllProperties on the Mock instance. The AutoMoqCustomization doesn't do that, but it's certainly possible to use the underlying types used to implement it to compose a different AutoMoqCustomization that also invokes SetupAllProperties.

In any case, this is only half of the solution, because it would only enable the Mock instance to get 'normal' property behavior. The other half would then be to make the AutoMoqCustomization automatically fill those properties. This is possible by wrapping the ISpecimenBuilder instance responsible for creating the actual interface instance in a PostProcessor. The following discussions may shed a little more light on these matters: Default Greedy constructor behavior breaks filling and Filling sub properties.

In short, I don't consider it a bug, but I do respect that other people may want different base behavior than I find appropriate. It's definitely possible to tweak AutoFixture to do what you want it to do, but perhaps a bit more involved than it ought to be. AutoFixture 3.0 should streamline the customization API somewhat, I hope.

As a side note, I consider properties in interfaces a design smell, so that's probably also why I've never had any issues with the current behavior.
2011-09-08 10:51 UTC
Thanks for your response. As I am using NSubstitute, I created an auto-mocking customization for it. I used the RhinoMocks customization as a template and changed it to support NSubstitute. I also implemented it the way I expected AutoMoq to behave, i.e. with filled properties.
Please see the fork I created: https://hg01.codeplex.com/forks/dhilgarth/autonsubstitute.
If you are interested, I can send a pull request.
2011-09-08 13:28 UTC
I think it is better to have AutoFixture behave consistent. When I request an anonymous instance, I expect its properties to be filled. I don't care if it's a concrete class I get or a mock because I asked for an anonymous instance of an interface. For me as a user it's not intuitive that they behave differently.
That's why I implemented it that way in AutoNSubstitute.


BTW, AutoMoq is in itself inconsistent: As I wrote in my original question, the property Child is not null but it contains a mock of ComplexChild. I understand your reasons for saying the properties should be null if a mock is returned, but then it should apply consistently to all properties.

Maybe it is a good idea to let the user of the customization choose what behavior he wants?
2011-09-08 14:19 UTC
Yes, I agree that consistency is desirable :)

As I mentioned, it's not something I've ever given a great deal of thought because I almost never define properties on interfaces, but I agree that it might be more consistent, so I've created a work item for it - you could go and vote for it if you'd like :)

Regarding your observation about the Child property, that's once more the behavior we get from Moq... The current implementation of AutoMoq basically just hands all mocking concerns off to Moq and doesn't deal with them any further.

Regarding your fork for NSubstitute I only had a brief look at it, but please do send a pull request - then we'll take it from there :)

Thank you for your interest.
2011-09-08 14:37 UTC

AutoFixture 2.0 beta 1

Monday, 09 August 2010 11:32:06 UTC

It gives me great pleasure to announce that AutoFixture 2.0 beta 1 is now available for download. Compared to version 1.1 AutoFixture 2.0 is implemented using a new and much more open and extensible engine that enables many interesting scenarios.

Despite the new engine and the vastly increased potential, the focus on version 2.0 has been to ensure that the current, known feature set was preserved.

What's new?

While AutoFixture 2.0 introduces new features, this release is first and foremost an upgrade to a completely new internal architecture, so the number of new releases is limited. Never the less, the following new features are available in version 2.0:

There are still open feature requests for AutoFixture, so now that the new engine is in place I can again focus on implementing some of the features that were too difficult to address with the old engine.

Breaking changes

Version 2.0 introduces some breaking changes, although the fundamental API remains recognizable.

  • A lot of the original methods on Fixture are now extension methods on IFixture (a new interface). The methods include CreateAnonymous<T>, CreateMany<T> and many others, so you will need to include a using directive for Ploeh.AutoFixture to compile the unit test code.
  • CreateMany<T> still returns IEnumerable<T>, but the return value is much more consistently deferred. This means that in almost all cases you should instantly stabilize the sequence by converting it to a List<T>, an array or similar.
  • Several methods are now deprecated in favor of new methods with better names.

A few methods were also removed, but only those that were already deprecated in version 1.1.

Roadmap

The general availability of beta 1 of AutoFixture 2.0 marks the beginning of a trial period. If no new issues are reported within the next few weeks, a final version 2.0 will be released. If too many issues are reported, a new beta version may be necessary.

Please report any issues you find.

After the release of the final version 2.0 my plan is currently to focus on the Idioms project, although there are many other new features that might warrant my attention.

Blog posts about the new features will also follow soon.


Comments

Arnis L.
One thing i somehow can't understand - when exactly there's a need for such a framework as AutoFixture?

P.s. Just don't read it wrong - I didn't say it's useless. Problem is with me. :)
2010-08-13 19:00 UTC
That's a reasonable question. The short answer is provided by AutoFixture's tag line: Write maintainable unit tests, faster.

For a more elaborate answer, you may want to read this, this and this. Also: stay tuned for more content.
2010-08-15 19:32 UTC
Arnis L.
Using it for awhile. Really nice tool. Less to write and think about. :)
2010-08-29 17:57 UTC

StructureMap PerRequest vs. Unique lifetimes

Tuesday, 20 July 2010 20:42:53 UTC

StructureMap offers several different lifetimes, among these two known as PerRequest and Unique respectively. Recently I found myself wondering what was the difference between those two, but a little help from Jeremy Miller put me on the right track.

In short, Unique is equivalent to what Castle Windsor calls Transient: every time an instance of a type is needed, a new instance is created. Even if we need the same service multiple times in the same resolved graph, multiple instances are created.

PerRequest, on the other hand, is a bit special. Each type can be viewed as a Singleton within a single call to GetInstance, but as Transient across different invocations of GetInstance. In other words, the same instance will be shared within a resolved object graph, but if we resolve the same root type once more, we will get a new shared instance - a Singleton local to that graph.

Here are some unit tests I wrote to verify this behavior (recall that PerRequest is StructureMap's default lifestyle):

[Fact]
public void ResolveServicesWithSameUniqueDependency()
{
    var container = new Container();
    container.Configure(x =>
    {
        var unique = new UniquePerRequestLifecycle();
        x.For<IIngredient>().LifecycleIs(unique)
            .Use<Shrimp>();
        x.For<OliveOil>().LifecycleIs(unique);
        x.For<EggYolk>().LifecycleIs(unique);
        x.For<Vinegar>().LifecycleIs(unique);
        x.For<IIngredient>().LifecycleIs(unique)
            .Use<Vinaigrette>();
        x.For<IIngredient>().LifecycleIs(unique)
            .Use<Mayonnaise>();
        x.For<Course>().LifecycleIs(unique);
    });
 
    var c1 = container.GetInstance<Course>();
    var c2 = container.GetInstance<Course>();
 
    Assert.NotSame(
        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,
        c1.Ingredients.OfType<Mayonnaise>().Single().Oil);
    Assert.NotSame(
        c2.Ingredients.OfType<Vinaigrette>().Single().Oil,
        c2.Ingredients.OfType<Mayonnaise>().Single().Oil);
    Assert.NotSame(
        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,
        c2.Ingredients.OfType<Vinaigrette>().Single().Oil);
}
 
[Fact]
public void ResolveServicesWithSamePerRequestDependency()
{
    var container = new Container();
    container.Configure(x =>
    {
        x.For<IIngredient>().Use<Shrimp>();
        x.For<OliveOil>();
        x.For<EggYolk>();
        x.For<Vinegar>();
        x.For<IIngredient>().Use<Vinaigrette>();
        x.For<IIngredient>().Use<Mayonnaise>();
    });
 
    var c1 = container.GetInstance<Course>();
    var c2 = container.GetInstance<Course>();
 
    Assert.Same(
        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,
        c1.Ingredients.OfType<Mayonnaise>().Single().Oil);
    Assert.Same(
        c2.Ingredients.OfType<Vinaigrette>().Single().Oil,
        c2.Ingredients.OfType<Mayonnaise>().Single().Oil);
    Assert.NotSame(
        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,
        c2.Ingredients.OfType<Vinaigrette>().Single().Oil);
}

Notice that in both cases, the OliveOil instances are different across two independently resolved graphs (c1 and c2).

However, within each graph, the same OliveOil instance is shared in the PerRequest configuration, whereas they are different in the Unique configuration.


Comments

Freddy Hansen
Thank you, I had missed the subtle difference here and your post saved me :-)
2012-10-23 18:58 UTC

Domain Objects and IDataErrorInfo

Monday, 12 July 2010 12:58:16 UTC

Occasionally I get a question about whether it is reasonable or advisable to let domain objects implement IDataErrorInfo. In summary, my answer is that it's not so much a question about whether it's a leaky abstraction or not, but rather whether it makes sense at all. To me, it doesn't.

Let us first consider the essence of the concept underlying IDataErrorInfo: It provides information about the validity of an object. More specifically, it provides error information when an object is in an invalid state.

This is really the crux of the matter. Domain Objects should be designed so that they cannot be put into invalid states. They should guarantee their invariants.

Let us return to the good old DanishPhoneNumber example. Instead of accepting or representing a Danish phone number as a string or integer, we model it as a Value Object that encapsulates the appropriate domain logic.

More specifically, the class' constructor guarantees that you can't create an invalid instance:

private readonly int number;
 
public DanishPhoneNumber(int number)
{
    if ((number < 112) ||
        (number > 99999999))
    {
        throw new ArgumentOutOfRangeException("number");
    }
    this.number = number;
}

Notice that the Guard Clause guarantees that you can't create an instance with an invalid number, and the readonly keyword guarantees that you can't change the value afterwards. Immutable types make it easier to protect a type's invariants, but it is also possible with mutable types - you just need to place proper Guards in public setters and other mutators, as well as in the constructor.

In any case, whenever a Domain Object guarantees its invariants according to the correct domain logic it makes no sense for it to implement IDataErrorInfo; if it did, the implementation would be trivial, because there would never be an error to report.

Does this mean that IDataErrorInfo is a redundant interface? Not at all, but it is important to realize that it's an Application Boundary concern instead of a Domain concern. At Application Boundaries, data entry errors will happen, and we must be able to cope with them appropriately; we don't want the application to crash by passing unvalidated data to DanishPhoneNumber's constructor.

Does this mean that we should duplicate domain logic at the Application Boundary? That should not be necessary. At first, we can apply a simple refactoring to the DanishPhoneNumber constructor:

public DanishPhoneNumber(int number)
{
    if (!DanishPhoneNumber.IsValid(number))
    {
        throw new ArgumentOutOfRangeException("number");
    }
    this.number = number;
}
 
public static bool IsValid(int number)
{
    return (112 <= number)
        && (number <= 99999999);
}

We now have a public IsValid method we can use to implement an IDataErrorInfo at the Application Boundary. Next steps might be to add a TryParse method.

IDataErrorInfo implementations are often related to input forms in user interfaces. Instead of crashing the application or closing the form, we want to provide appropriate error messages to the user. We can use the Domain Object to provide validation logic, but the concern is completely different: we want the form to stay open until valid data has been entered. Not until all data is valid do we allow the creation of a Domain Object from that data.

In short, if you feel tempted to add IDataErrorInfo to a Domain Class, consider whether you aren't about to violate the Single Responsibility Principle. In my opinion, this is the case, and you would be better off reconsidering the design.


Comments

onof
I agree.

Too often i see domain objects implementing a lot of validation code. I think that most of validation logic must be out of domain objects.
2010-07-12 15:05 UTC
Arnis L
People are struggling with understanding what they are validating, where they put their validation but i kind a think that nature of validity itself is often forgotten, unexplored or misunderstood.

DanishPhoneNumber value can't be less than 112. In reality we are modeling - such a phone number just does not exist. So it makes sense to disallow existence of such an object and throw an error immediately.

But there might be cases when domain contains temporary domain object invalidity from specific viewpoint/s.

Consider good old cargo shipment domain from Blue book. Shipment object is invalid and shouldn't be shipped if there's no cargo to ship and yet such a shipment can exist because it's planned out gradually. In these kind of situations - it might make sense to use IDataErrorInfo interface.
2010-07-13 13:44 UTC
I would prefer to disagree :)

We must keep in mind that we are not modeling the real world, but rather the business logic that addresses the real world. In your example, that would be represented by a proper domain object that models that a shipment is still in the planning stage. Let's call this object PlannedShipment.

According to the domain model, PlannedShipment has its own invariants that it must protect, and the point still remains: PlannedShipment itself cannot be in an invalid state. However, PlannedShipment can't be shipped because it has not yet been promoted to a 'proper' Shipment. Such an API is safer because it makes it impossible to introduce errors of the kind where the code attempts to ship an invalid Shipment.
2010-07-13 14:58 UTC
I think it is a very interesting thought to make domain objects immutable. However, I’m very curious about the practical implications of this. For instance: are all your domain objects immutable? Do you create them by using constructors with many arguments (because some domain objects tend to have many properties? It gets really awkward when constructors have many (say more than 5) arguments. How do you deal with this? Which O/RM tool(s) are you using for this immutability and how are you achieving this. Some O/RM tools will probably be a bad pick in trying to implement this. How are you dealing with updating existing entities? Creating a new entity with the same id seems rather awkward and doesn't seem to communicate its intent very well IMO. I love to see some examples.

Thanks
2010-07-13 20:08 UTC
I never said that all Domain Objects should be immutable - I'm using the terminology from Domain-Driven Design that distinguishes between Entities and Value Objects.

A Value Object benefits very much from being immutable, so I always design them that way, but that doesn't mean that I make Entities immutable as well. I usually don't, although I'm sometimes toying with that idea.

In any case, if you have more than 4 or 5 fields in a class (no matter if you fill them through a constructor or via property setters), you most likely have a new class somewhere in there waiting to be set free. Clean Code makes a pretty good case of this. Once again, too many primitives in an Entity is a smell that the Single Responsibility Principle is violated.
2010-07-14 09:06 UTC
It's very uncommon that i disagree with you, but...

With your phone number example in mind, the validation should imho never be encapsulated in the domain object, but belong to a separate validation. When you put validation inside the constructor you will eventually break the . Of course we have to validate for null input if they will break the functionality, but I would never integrate range check etc. into the class it self.
2010-07-15 20:28 UTC
You'll have to define the range check somewhere. If you put it in an external class, I could repeat your argument there: "your DanishPhoneNumberRangeValidator isn't open for extensibility." Value Objects are intrinsically rather atomic, and not particularly composable, in scope.

However, consumers of those Value Objects need not be. While I didn't show it, DanishPhoneNumber could implement IPhoneNumber and all clients consume the interface. That would make DanishPhoneNumber a leaf of a composition while still keeping the architecture open for extensibility.

The point is to define each type so that their states are always consistent. Note that for input gatherers, invalid data is considered consistent in the scope of input gathering. That's where IDataErrorInfo makes sense :)
2010-07-15 21:13 UTC
Arnis L
In short - I just wanted to mention nature of validity itself.

Second thing I wanted to emphasize is about Your sentence of making sense - we should focus on technology we are using not only to be able to express ourselves, but to be aware (!) of how we are doing it and be able to adjust that.

Patterns, OOP, .NET, POCO and whatnot are tools only. IDataErrorInfo is a tool too. Therefore - if it feels natural to use it to express our domain model (while it's suboptimal cause of arguments You mentioned), there is nothing wrong with using it per se. An agreement that our domain model objects (in contrast to reality) can be invalid if it simplifies things greatly (think ActiveRecord) is a tool too.
2010-07-20 08:51 UTC
I think we can often construct examples where the opposite of our current stance makes sense. Still, I like all rules like the above because they should first and foremost make us stop and think about what we are doing. Once we've done that, we can forge ahead knowing that we made a conscious decision - no matter what we chose.

To me, internal consistency and the SRP is so important that I would feel more comfortable having IDataErrorInfo outside of domain objects, but there are no absolutes :)
2010-07-20 09:35 UTC

Introducing AutoFixture Likeness

Tuesday, 29 June 2010 06:39:30 UTC

The last time I presented a sample of an AutoFixture-based unit test, I purposely glossed over the state-based verification that asserted that the resulting state of the basket variable was that the appropriate Pizza was added:

Assert.IsTrue(basket.Pizze.Any(p =>
    p.Name == pizza.Name), "Basket has added pizza.");

The main issue with this assertion is that the implied equality expression is rather weak: we consider a PizzaPresenter instance to be equal to a Pizza instance if their Name properties match.

What if they have other properties (like Size) that don't match? If this is the case, the test would be a false negative. A match would be found in the Pizze collection, but the instances would not truly represent the same pizza.

How do we resolve this conundrum without introducing equality pollution? AutoFixture offers one option in the form of the generic Likeness<TSource, TDestination> class. This class offers convention-based test-specific equality mapping from TSource to TDestination and overriding the Equals method.

One of the ways we can use it is by a convenience extension method. This unit test is a refactoring of the test from the previous post, but now using Likeness:

[TestMethod]
public void AddWillAddToBasket_Likeness()
{
    // Fixture setup
    var fixture = new Fixture();
    fixture.Register<IPizzaMap, PizzaMap>();
 
    var basket = fixture.Freeze<Basket>();
 
    var pizza = fixture.CreateAnonymous<PizzaPresenter>();
    var expectedPizza = 
        pizza.AsSource().OfLikeness<Pizza>();
 
    var sut = fixture.CreateAnonymous<BasketPresenter>();
    // Exercise system
    sut.Add(pizza);
    // Verify outcome
    Assert.IsTrue(basket.Pizze.Any(expectedPizza.Equals));
    // Teardown
}

Notice how the Likeness instance is created with the AsSource() extension method. The pizza instance (of type PizzaPresenter) is the source of the Likeness, whereas the Pizza domain model type is the destination. The expectedPizza instance is of type Likeness<PizzaPresenter, Pizza>.

The Likeness class overrides Equals with a convention-based comparison: if two properties have the same name and type, they are equal if their values are equal. All public properties on the destination must have equal properties on the source.

This allows me to specify the Equals method as the predicate for the Any method in the assertion:

Assert.IsTrue(basket.Pizze.Any(expectedPizza.Equals));

When the Any method evalues the Pizze collection, it executes the Equals method on Likeness, resulting in a convention-based comparison of all public properties and fields on the two instances.

It's possible to customize the comparison to override the behavior for certain properties, but I will leave that to later posts. This post only scratches the surface of what Likeness can do.

To use Likeness, you must add a reference to the Ploeh.SemanticComparison assembly. You can create a new instance using the public constructor, but to use the AsSource extension method, you will need to add a using directive:

using Ploeh.SemanticComparison.Fluent;


Comments

DavidS
Hi Mark,

In your example, you are only comparing one property and I know that you can test many properties as well.

Now it is my understanding that given many properties if any property doesn't match, then you'll get a test failure. My question is how to output a message pinpointing which property is causing the test to fail.

On another note, maybe you could ask Adam Ralph how he's integrated the comment section on his blog, which I believe is using the same platform as you are. http://adamralph.com/2013/01/09/blog-post-excerpts-a-new-solution/

2013-04-18 12:40 UTC

David, if you want to get more detailed feedback on which properties don't match, you can use expected.ShouldEqual(actual);

2013-04-18 21:33 UTC

Upcoming talks spring 2010

Sunday, 23 May 2010 16:11:37 UTC

In the next couple of weeks I will be giving a couple of talks in Copenhagen.

At Community Day 2010 I will be giving two talks on respectively Dependency Injection and TDD.

In early June I will be giving a repeat of my previous CNUG TDD talk.


Sneak view at Castle's WCF Facility

Tuesday, 18 May 2010 05:27:56 UTC

One of Castle Windsor's facilities addresses wiring up of WCF services. So far, the sparse documentation for the WCF Facility seems to indicate that you have to configure your container in a global.asax. That's not much to my liking. First of all, it reeks of ASP.NET, and secondly, it's not going to work if you expose WCF over protocols other than HTTP.

However, now that we know that a custom ServiceHostFactory is effectively a Singleton, a much better alternative is to derive from the WCF Facility's DefaultServiceHost class:

public class FooServiceHostFactory : 
    DefaultServiceHostFactory
{
    public FooServiceHostFactory()
        : base(FooServiceHostFactory.CreateKernel())
    {
    }
 
    private static IKernel CreateKernel()
    {
        var container = new WindsorContainer();
 
        container.AddFacility<WcfFacility>();
 
        container.Register(Component
            .For<FooService>()
            .LifeStyle.Transient);
        container.Register(Component
            .For<IBar>()
            .ImplementedBy<Bar>());
 
        return container.Kernel;
    }
}

Although it feels a little odd to create a container and then not really use it, but only its Kernel property, this works like a charm. It correctly wires up this FooService:

public class FooService : IFooService
{
    private readonly IBar bar;
 
    public FooService(IBar bar)
    {
        if (bar == null)
        {
            throw new ArgumentNullException("bar");
        }
 
        this.bar = bar;
    }
 
    #region IFooService Members
 
    public string Foo()
    {
        return this.bar.Baz;
    }
 
    #endregion
}

However, instead of the static CreateKernel method that creates the IKernel instance, I suggest that the WCF Facility utilizes the Factory Method pattern. As the WCF Facility has not yet been released, perhaps there's still time for that change.

In any case, the WCF Facility saves you from writing a lot of infrastructure code if you would like to wire your WCF services with Castle Windsor.


Comments

There's a plan to provide Facility's base ServiceHostFactory that you could use out of the box with very minimal anmount if XML config in your web.config/app.config file:

<installers>
<install assembly="Ploeh.AssemblyContainingWindsorInstallers"/>
</ installers>

See http://stw.castleproject.org/Windsor.Registering-Installers.ashx

Alternatively you could override protected IWindsorInstaller GetInstallers(); method and configure the container entirely in code.

Thoughts?
2010-05-18 08:24 UTC
That would definitely address most cases, including the one I'm currently looking at, although I'm not sure I understand your last sentence. Did you mean that I can implement a custom IWindsorInstaller? If so, that makes a lot of sense.

For the edge cases where adding an Installer isn't enough, I'd still prefer a Factory Method hook in DefaultServiceHostFactory, but being able to specify an Installer in web.config will likely address 90 percent (or more) of scenarios.

Looks good!
2010-05-18 08:38 UTC
In both cases you will need to provide your own implementation of IWindsorInstaller that will provide services and configuration to the container. The difference between the two approaches is as follows:

If you use Facility's default SH Factory it will look into your web.config for informations about how to configure itself.
ALternativelty you can provide your own subclass of the SH Factory, override its protected IWindsorInstaller[] GetInstallers(); method and then you'll be able to configure the container without using config file.
2010-05-18 08:45 UTC
Why would you prefer factory method instead of just pointing to installers? What do you need to do that the other approach can't address?
2010-05-18 08:47 UTC
Thanks for your explanation. I think that sounds very promising. As far as I can tell, this is still in the future, right? I don't see any GetInstallers() on DefaultServiceHostFactory right now (based on the code I downloaded and compiled last week).

Don't get me wrong on the Factory Method thing. I don't expect to need it often (if at all), but I just think it would be a good OCP thing to do... Off the top of my head, I can't remember whether there are things you can do to a container that you can't do from an Installer. Maybe there aren't...
2010-05-18 09:05 UTC
you're right, GetInstallers() is not there yet, (same as specifying installers in xml is part of trunk, not v2.1).

I do intend to leave the door open with factory method for people who can't use xml even if it's so minimal (or feel sick when even thinking about xml), but as you said - there really isn't anything you couldn't do from installer so I imagine it would be for emergency cases only.
2010-05-18 09:15 UTC

ServiceHostFactory lifetime

Monday, 17 May 2010 05:42:33 UTC

For a while I've been wondering about the lifetime behavior of custom ServiceHostFactory classes hosted in IIS. Does IIS create an instance per request? Or a single instance to handle all requests?

I decided to find out, so I wrote a little test service. The conclusion seems to be that there is only a single instance that servers as a factory for all requests. This is very fortunate, since it gives us an excellent place to host a DI Container. The container can then manage the lifetime of all components, including Singletons that will live for the duration of the process.

If you are curious how I arrived at this conclusion, here's the code I wrote. I started out with this custom ServiceHostFactory:

public class PocServiceHostFactory : ServiceHostFactory
{
    private static int number = 1;
 
    public PocServiceHostFactory()
    {
        Interlocked.Increment(
            ref PocServiceHostFactory.number);
    }
 
    protected override ServiceHost CreateServiceHost(
        Type serviceType, Uri[] baseAddresses)
    {
        return new PocServiceHost(
            PocServiceHostFactory.number, serviceType,
            baseAddresses);
    }
}

The idea is that every time a new instance of ServiceHostFactory is created, the static number is incremented.

The PocServiceHostFactory just forwards the number to the PocServiceHost:

public class PocServiceHost : ServiceHost
{
    public PocServiceHost(int number, Type serviceType,
        Uri[] baseAddresses)
        : base(serviceType, baseAddresses)
    {
        foreach (var cd in 
            this.ImplementedContracts.Values)
        {
            cd.Behaviors.Add(
                new NumberServiceInstanceProvider(
                    number));
        }
    }
}

The PocServiceHost just forwards the number to the NumberServiceInstanceProvider:

public class NumberServiceInstanceProvider : 
    IInstanceProvider, IContractBehavior
{
    private readonly int number;
 
    public NumberServiceInstanceProvider(int number)
    {
        this.number = number;
    }
 
    #region IInstanceProvider Members
 
    public object GetInstance(
        InstanceContext instanceContext,
        Message message)
    {
        return this.GetInstance(instanceContext);
    }
 
    public object GetInstance(
        InstanceContext instanceContext)
    {
        return new NumberService(this.number);
    }
 
    public void ReleaseInstance(
        InstanceContext instanceContext,
        object instance)
    {
    }
 
    #endregion
 
    #region IContractBehavior Members
 
    public void AddBindingParameters(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        BindingParameterCollection bindingParameters)
    {
    }
 
    public void ApplyClientBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        ClientRuntime clientRuntime)
    {
    }
 
    public void ApplyDispatchBehavior(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint,
        DispatchRuntime dispatchRuntime)
    {
        dispatchRuntime.InstanceProvider = this;
    }
 
    public void Validate(
        ContractDescription contractDescription,
        ServiceEndpoint endpoint)
    {
    }
 
    #endregion
}

The relevant part of NumberServiceInstanceProvider is the GetInstanceMethod that simply forwards the number to the NumberService:

public class NumberService : INumberService
{
    private readonly int number;
 
    public NumberService(int number)
    {
        this.number = number;
    }
 
    #region INumberService Members
 
    public int GetNumber()
    {
        return this.number;
    }
 
    #endregion
}

As you can see, NumberService simply returns the injected number.

The experiment is now to host NumberService in IIS using PocServiceHostFactory. If there is only one ServiceHostFactory per application process, we would expect that the same number (2) is returned every time we invoke the GetNumber operation. If, on the other hand, a new instance of ServiceHostFactory is created per request, we would expect the number to increase for every request.

To test this I spun up a few instances of WcfTestClient.exe and invoked the operation. It consistently returns 2 across multiple clients and multiple requests. This supports the hypothesis that there is only one ServiceHostFactory per service process.


Comments

onof
There's a project on codeplex

http://containerservicehost.codeplex.com/documentation
2010-05-17 07:10 UTC

Fun with literal extensions and Ambient Context

Tuesday, 27 April 2010 04:24:25 UTC

My book contains a section on the Ambient Context pattern that uses a TimeProvider as an example. It's used like this:

this.closedAt = TimeProvider.Current.UtcNow;

Yesterday I was TDDing a state machine that consumes TimeProvider and needed to freeze and advance time at different places in the test. Always on the lookout for making unit tests more readable, I decided to have a little fun with literal extensions and TimeProvider. I ended up with this test:

// Fixture setup
var fixture = new WcfFixture();
 
DateTime.Now.Freeze();
 
fixture.Register(1.Minutes());
var sut = fixture.CreateAnonymous<CircuitBreaker>();
sut.PutInOpenState();
 
2.Minutes().Pass();
// Exercise system
sut.Guard();
// Verify outcome
Assert.IsInstanceOfType(sut.State,
    typeof(HalfOpenCircuitState));
// Teardown

There are several items of note. Imagine that we can freeze time!

DateTime.Now.Freeze();

With the TimeProvider and an extension method, we can:

internal static void Freeze(this DateTime dt)
{
    var timeProviderStub = new Mock<TimeProvider>();
    timeProviderStub.SetupGet(tp => tp.UtcNow).Returns(dt);
    TimeProvider.Current = timeProviderStub.Object;
}

This effectively sets up the TimeProvider to always return the same time.

Later in the test I state that 2 minutes pass:

2.Minutes().Pass();

I particularly like the grammatically correct English. This is accomplished with a combination of a literal extension and changing the state of TimeProvider.

First, the literal extension:

internal static TimeSpan Minutes(this int m)
{
    return TimeSpan.FromMinutes(m);
}

Given the TimeSpan returned from the Minutes method, I can now invoke the Pass extension method:

internal static void Pass(this TimeSpan ts)
{
    var previousTime = TimeProvider.Current.UtcNow;
    (previousTime + ts).Freeze();
}

Note that I just add the TimeSpan to the current time and invoke the Freeze extension method with the new value.

Last, but not least, I should point out that the PutInOpenState method isn't some smelly test-specific method on the SUT, but rather yet another extension method.


Changing Windsor lifestyles after the fact

Monday, 26 April 2010 05:09:42 UTC

I recently had the need to change the lifestyles of all components in a WindsorContainer (read on to the end if you want to know why). This turned out to be amazingly simple to do.

The problem was this: I had numerous components registered in a WindsorContainer, some of them as Singletons, some as Transients and yet again some as PerWebRequest. Configuration was even defined in numerous IWindsorInstallers, including some distributed XML files. I now needed to spin up a second container with the same configuration as the first one, except that the lifestyles should be all Singletons across the board.

This can be easily accomplished by implementing a custom IContributeComponentModelConstruction type. Here's a simple example:

Consider this IWindsorInstaller:

public class FooInstaller : IWindsorInstaller
{
    #region IWindsorInstaller Members
 
    public void Install(IWindsorContainer container,
        IConfigurationStore store)
    {
        container.Register(Component
            .For<IFoo>()
            .ImplementedBy<Foo>()
            .LifeStyle.Transient);
    }
 
    #endregion
}

The important point to notice is that it registers the lifestyle as Transient. In other words, this container will always return new Foo instances:

var container = new WindsorContainer();
container.Install(new FooInstaller());

We can override this behavior by adding this custom IContributeComponentModelConstruction:

public class SingletonEqualizer :
    IContributeComponentModelConstruction
{
    public void ProcessModel(IKernel kernel, 
        ComponentModel model)
    {
        model.LifestyleType = LifestyleType.Singleton;
    }
}

In this very simple example, I always set the lifestyle type to the same value, but obviously we can write as complex code in the ProcessModel method as we would like. We can now configure the container like this:

var container = new WindsorContainer();
container.Kernel.ComponentModelBuilder
    .AddContributor(new SingletonEqualizer());
container.Install(new FooInstaller());

With this configuration we will now get the same instance of Foo every time we Resolve IFoo.

We did I need this? Because my application is a web application and I'm using the PerWebRequest lifestyle in a number of places. However, I needed to spin up a second container that would compose object hierarchies for a background process. This background process needs the same component configuration as the rest of the application, but can't use the PerWebRequest lifestyle as there will be no web request available to the background process. Hence the need to change lifestyles across the board.


Page 34 of 42

"Our team wholeheartedly endorses Mark. His expert service provides tremendous value."
Hire me!