AutoMoqBoostCustomization

`AutoMoqBoostCustomization` is a customization that builds on top of AutoMoq's `AutoMoqCustomization`.

`AutoMoqBoostCustomization` uses the existing `MockPostprocessor` to allows mocks to be retrieved from a fixture, and adds its own `MockSetup` to automatically setup mocks created by the post-processor before returning them to the client.

The mock's members (methods/properties/indexers) will be set up in such a way that return values will be retrieved from a fixture (see examples below). Also, if a method contains any "out" parameters, the value for the outcome of these parameters will also be fetched from a fixture.

`MockSetup` is composed by a collection of `IMockInitializer`s, each of them responsible for setting up certain members of the mock object. Currently, 2 initializers are provided (although the client is free to define his/her own initializers):

#### SealedPropertyInitializer

This initializer will inspect a mock's members and check for any properties that cannot be setup by Moq, i.e., any sealed/non-overridable properties.

Each of these properties will be setup in the following manner:

    mock.Object.Member = fixture.Create<TMember>();

#### VirtualMethodInitializer

This initializer will inspect a mock's members and check for any methods that can be setup by Moq, i.e., any virtual/abstract/non-sealed methods.

Each of these methods will be set up in a manner similar to this:

```csharp
//setting up "public int Method(string p1)"
mock.Setup(m => m.Method(It.IsAny<string>()))
    .Returns(() => {
          var result = fixture.Create<int>();            //retrieve value from the fixture (lazily)
          mock.Setup(m => m.Method(It.IsAny<string>()))
              .Returns(result);                          //reuse this value the next time the member is invoked
          return result;
    });
```

If the method being set up contains any "out" parameters, then the setup becomes:

```csharp
//setting up "public int Method(string p1, out bool p2)"
//value for the "out" parameter must be retrieved eagerly
var outParameter = fixture.Create<bool>();        
mock.Setup(m => m.Method(It.IsAny<string>(), out outParameter))
    .Returns(() => {
          var result = fixture.Create<int>();
          mock.Setup(m => m.Method(It.IsAny<string>(), out outParameter)))
              .Returns(result);
          return result;
    });
```

In order for a method to be eligible for setup, it needs to:
* be overridable (self-explanatory);
* either be non-void *or* have "out" parameters.
    * If the method is void and has no "out" parameters then there is nothing worth setting up.
* not have ref parameters;
    * due to a limitation in Moq (see the third example in the [Quickstart][2]), a setup for a method with a "ref" parameter will only be matched if the variable used to setup the method is the same as the one used to call the method. Since the setup and the invocation take place in completely different scopes, automatic setup of a method with "ref" parameters is therefore impossible.
* not be generic;
    * automatic mocking of generic methods isn't feasible either - we'd have to antecipate any type parameters that this method could be called with. Note that methods that belong to a generic type, but don't introduce any generic type parameters of their own are *not* considered generic themselves and can, therefore, be automatically setup.
    * in order to simplify manual mocking of generic methods, the `ReturnsUsingFixture` public extension method is available. Usage: 
    ```csharp    
converter.Setup(x => x.Convert<double>("10.0"))
             .ReturnsUsingFixture(fixture);
    ```



Note that properties and indexers are also implemented as methods (e.g., `get_Age()` and `get_Item(Int32)` respectively). As follows, the `VirtualMethodInitializer` will also set these up.



**Notes**: 
* The `ReturnsUsingFixture` extension method was added to the `MockType` static class. This class was made public, but all other methods remain internal.
* The extension method, the `IMockInitializer` interface and the `Setup` method on both implementations of this interface were marked with `[CLSCompliant(false)]` because their arguments are not CLS compliant. Let me know if there is a more desirable approach to this issue.
* This started out as a separate project entitled `AutoMoq.Boost`, available [here][1]. This project will be marked as "migrated" and discontinued once the pull request is accepted.

 [1]: https://github.com/dcastro/AutoMoq.Boost
 [2]: https://github.com/Moq/moq4/wiki/Quickstart

The main reason I objected to the changes of white space is that it makes it more difficult for me to review the pull requests, because it looks as though there are more changes than there actually is.

Apart from that, I do believe that a thriving open source project should allow individual programmers to use their individual coding styles (within certain limits), as long as the public API stays consistent.

So, if you want to arrange code in a certain way for new code that you write, feel free to use any sensible scheme. However, I'd prefer that you don't touch existing code unless necessary.

(For the record, I don't agree with the way ReSharper formats code, because it produces inconsistent indentation, which, I believe, makes the code more difficult to read. For an in-depth treatment of this topic, see Kevlin Henney's recorded presentation [Seven Ineffective Coding Habits of Many Programmers](http://vimeo.com/97329157).)