With the popularity of Single-Page Applications (SPAs) frameworks like Vue.js, React, and Angular and static site generators like Jekyll or Hugo, website no longer need an active server like IIS or Tomcat to host the site. Instead, you just need somewhere to host the files and serve them up from a hostname.

At the end of 2018, Azure added the ability to host static websites from Azure Blob Storage. This becomes a fairly cheap way to host, since you only pay for storage (very cheap) and for network usage (also cheap). This seems like a great option for me when I recently converted a site previously running Wordpress inside an Azure Application Service. I converted the site to a SPA and wanted to host it, using a custom domain, via this new feature.

I ran some proof-of-concents and everything was working great, so I went to make the site live at the custom hostname for the existing site, including a TLS cert to enable HTTPS. This is where everything fell apart. Azure static sites support custom domains and support HTTPS, both through the use of the Azure CDN feature, and even have the ability to manage those certs automaticly via the Azure portal once you validation domain ownership.

EXCEPT for this one little note in the Prerequisites section of the Microsoft docs tuitorial for setting it up:

Important

CDN-managed certificates are not available for root or apex domains. If your Azure CDN custom domain is a root or apex domain, you must use the Bring your own certificate feature.

So if I want to have www.mydomain.com, all is good. But as soon as I want to use just mydomain.com, I can no longer use the built-in automation with Azure, and figuring out how to actually do the "Bring your own certificate" steps was a huge pain in the ass.

My goal here is to document the process I went through to enable HTTPS on a root domain for a static website in Azure storage.

I'm assuming you already have an Azure account and are somewhat familiar with the Azure portal, and that you already have a custom domain that you can manage (via Azure or a third-party provider) to add additional DNS records.

Part 1: Starting with the Static Website

Difficulty: Easy
Time required: Not much

Setting up the static website itself was pretty straightforward, using the auto-assigned domain name. The official documentation from Microsoft walks you through this, but the short version is this:

• Create an Azure Storage Account
• In the Azure Portal, open the Static website pane from the Settings menu for the store account
• Click the toggle to "Enable" static websites for the storage account

This creates a $web container in the Blob storage area of the storage account. This is the folder that becomes your static site. Azure also creates two endpoints (aka hostnames) that point to this static site. Since we'll be adding a CDN for this site in a minute, we really only need to care about the "primary" endpoint.

At this point, if you created an index.html file in the $web container, you could point your browser at the primary endpoint url and it will serve up that file as if it were being hosted from a formal webserver.

In my case, I'm using VSCode to write my SPA site, and I've added the Azure Storage entension for VSCode. This allows me to easily deploy my site files to my new static website container in Azure by right-clicking on the $web container in the VSCode Azure pane and choosing "Deploy to Static Website..."

Part 2: Adding a Content Distribution Network (CDN) Endpoint

Difficulty: Easy to Medium
Time required: Not much

Great, so we've got a static website up and running, but the website URL is https://mystorageaccountname.z14.web.core.windows.net/ and that's not what I want.

In order to use custom domains (and custom domain certs) with storage-based static sites, you must use the Azure CDN. Again, the official Microsoft documentation is well done, but the short version is this:

• Create a CDN Profile and add a CDN endpoint that points to the "primary" endpoint of your storage account static site.

Important: You must use Azure CDN from Microsoft or Azure CDN from Verizon profiles in order to use a custom HTTPS certificate, which is required for custom root domains. I used Azure CDN from Microsoft.

Pretty simple. You'll get to provide the name you want to use, which will ultimate generate a CDN-backed URL like https:\\mycdnname.azureedge.net.

NOTE: At this point, Azure has auto-genearted HTTPS certs for each of the URLs it's generated, so HTTPS is enabled , but it's using the azureedge.net or windows.net domain names.

Part 3: Use Your Custom Domain for the CDN Endpoint

Difficulty: Easy to Medium
Time required: 5-10 minutes

Now you need to associate your custom domain with the CDN endpoint. As part of this process, Microsoft wants to make sure you actually own the domain you're attempting to use, so you have to do some verifications. There are a handful of ways to do this, including: creating DNS records with specific names under the domain, adding specifically-name html files to website on that domain, responding to an email sent to the address listed on the DNS ownership record.

For me, the easiest route was to modify the DNS records, and I'd suggest going this route for a couple of reasons:

1. If you don't actually list your personal contact on your DNS registration (you use some privacy service, for example), then you can't use the email option
2. With DNS, you can have the option of using verification-specific entries instead of your production entries, thus allowing you to stage your changes ahead of time without impacting production.
3. You're going to have to change your DNS eventually in order to point your domain to the new static website, so might as well do it here.

In this case, the offical docs aren't so good, so here's a walkthrough of what I did:

Step 1: You'll need to create new CNAME or AAAA DNS records to either

1. point cdnverify.yourdomain.com to cdnverify.yourcdnname.azureedge.net
2. point yourdomain.com to yourcdn.azureedge.net

By using the cdnverify CNAME, you can confirm ownership without having to change the real DNS yet.

I'm using Azure as my DNS provider for this particular domain, but that's not required. You could use any DNS provider. I would suggest using a very short TTL (Time To Live -- or caching period) for the DNS record, just in case you get it wrong the first time -- otherwise you may have to wait for DNS to repropigate to fix any issue.

Step 2: Once you have the cdverify DNS record (or the main record) pointing to the CDN endpoint, you can move on to adding the custom domain to the CDN endpoint. In the Azure portal, pull up the CDN endpoint record and select "Custom Domains" from the navigation pane. Then click the "+ Custom domain" button.

In the "Add a Custom Domain" dialog, enter the actual domain name for your CDN endpoint into the "Endpoint hostname" field (ie: youcdn.azureedge.net), and enter your custom domain name into the "Custom hostname" field. Do not use the cdnverify. hostname -- use the actual hostname.)

As you enter the "Custom hostname" value, Azure will do DNS lookups on what you enter and check that the domain is pointing at the CDN domain, or the cdnverify version of the domain is pointed at the CDN cdverify domain. If that resolution is successful, you'll get a little green checkmark at the end of the input text box. Otherwise, you'll get a red exclaimation point with a mouse-over dialog saying it couldn't do the verfication. If you get the red error mark, first double-check you didn't typo the hostname, then double-check your DNS entries.

Once you get the green checkbox, click the "Add" button.

This will start the background process of creating the custom domain CDN associatation. This will take a minute or two to complete, after which you'll see the entry listed on the Custom domains pane, with "Disabled" in the "Custom HTTPS" column:

Part 4: Enabling HTTPS for Your CDN Endpoint Custom Domain

This is where things start to get ugly.

You have two paths to choose here, Mr Anderson:

If you take the blue pill, you can use a non-root domain (ie: www.yourdomain.com -- note the www sub-domain), and live in a utopian land where Azure handles all the provisioning and renewals of your HTTPS certs for you for free, and you only need to set "Custom domain HTTPS" to "On" for the CDN endpoint, and select the "CDN managed" option. (Just follow the offical Microsoft walkthrough.) The story ends, you wake up in bed and believe whatever you want to believe.

If you take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember: all I'm offering is the truth.

Ok, enough Matrix references.

At this point, you're still here because you either want to use a root domain for your static site, or maybe you have an SSL cert already that you really want to use and manage yourself. So here goes...

In order to use a root domain (like example.com), you must use the "Bring your own certificate" option. This path is not well documented, so I'm going to walk through how I achieved it.

Add your cert to the Azure Vault

Azure won't create a security cert for you for your root domain. That means you have to buy one. I'm hoping this changes, and soon, because in this era of Let's Encrypt giving everyone free certs -- and even Azure giving free certs to any non-root domain -- I don't understand the reasoning for making people pay for these root-level certs.

Do not pay hundreds of dollars for your HTTPS cert! As of Aug 2019, if you go to be "big name" providers, like Comodo (prices start at $88/year) or DigiCert (starts at $207 for 2-year cert), you'll pay too much. You do need to use an Azure-approved cert authority, but I highly suggest namecheap where you can get a single-domain HTTPS certificate for $8/year or a multi-domain cert for about $20/yr. Note: You only need a single-domain, since you only need this cert for the root domain, but in my case I went ahead and got a multi-domain and used it for both the root and www domain. Technically, I could have used a free cert from Azure for the www domain.

The process of getting a cert you can upload into Azure goes like this:

• Create an unsigned cert in Azure Key Vault
• Use that unsigned cert to generate a "Certificate Signing Request" (CSR) from Azure
• Provide that CSR to your certificate authority. Go through whatever process they require to validate your request.
• Take the signed certificate generated by the cert authority and upload it into Azure Key Vault

That's the overview. Here's the details:

Step 1: Create an unsigned cert in Azure Key Vault

Difficulty: Easy
Time required: Very little

Create an Azure Key Vault in the Resource Group with your static website and CDN instances. Within the Vault, go to the "Certificates" pane and click "Generate/Import" button.

In the "Create a Certificate" dialog, enter the following:

• For "Method of Certificate Creation", choose "Generate"
• For "Certificate Name", pick any name you want to identify the record -- but remove any symbols and whitespace
• For "Type of Certificate Authority (CA)", pick "Certificate issued by a non-integrated CA"
• For "Subject", use CN=yourdomain.com (ie: CN= followed by your domain name)
• Click on the "DNS Names" section and enter your domain. If you want to have multiple domains on the cert (such as the root domain and the www domain: type one, press [tab] to enter that one and get a new text box to enter the next domain. Once you have all the domains entered, click "OK"
• For "Validity Period", pick how long you want the cert to be valid. This doesn't have to match the length you purchaged from your certificate authority -- it can't be longer, but it can be shorter. If it's shorter, you should be able to request an updated cert without charge around the time the current cert expires.
• For "Content Type", check with your cert auth to see what they support, but I would default to PEM.
• For the "Lifetime Action Type" and the reamining inputs, decide how you want the system to notify you when the cert is about to expire. I would suggest having it email you within about a month of expiration.
• Click "Create"

Your cert should be created immediately, but marked as "Disabled".

Step 2: Get the cert signed by your Certificate Authority and upload it back to Azure

Difficulty: Easy
Time required: 15min or more, depending on your CA's turnaround time

Click on the cert entry to open its details, then click the "Certificate Operations" button. On the resulting dialog, click the "Download CSR" button.

This will download a Certificate Signing Request file, which is basically all of the details that would go into a signed cert, plus some server information. If you want to see the actual data in the file, you can use this SSL & CSR decoder tool.

Now you'll need to hand this CSR file off to your certificate authority. For me, using namecheap as my certificate authority, I had to upload the CSR and then had to add more CNAME DNS entries to prove I owned the domains listed in the cert request. (They provided the instructions for what domains to create and where they should point). Once they are able to verify ownership via DNS entries, it took about 15 mins for them to inform me (via email) that my cert was ready and I was able to download a PEM file that included three entries:

• the CSR I submitted
• the signed cert
• the RSA private key

BE CAREFULL WITH THIS FILE. It includes the private key, so anyone with this file could pretend to be your server. Treat it like you would a password.

You should get that same file from your cert authority. Once you have it, go back to the same screen in Azure where you created the CSR and this time choose "Merge Signed Request" and upload the file with the signed cert and private key.

If all goes well, you'll see the cert now listed as "Enabled"

Give Azure CDN access to your Key Value

Difficulty: Medium
Time required: under 15 mins

The CDN service needs permissions to read from the Azure Key Vault in order to fetch your HTTPS cert. Unfortunately, you can't do this next step in the web portal, so you have to use some PowerShell commands.

Open a PowerShell prompt and run the following:

This will install the Azure AD CLI (Command Line Interface) for PowerShell, which is needed for the next two commands:

Install-Module AzureAD

Authenticate with Azure:

Connect-AzAccount

Give the Azure CDN service account an AD Principal in your default Azure AD instance: Note: The GUID in this command is the same for everyone -- no need to change it.

New-AzADServicePrincipal -ApplicationId "205478c0-bd83-4e1b-a9d6-db63a3e1e1c8" -Verbose

Now, back in the Azure portal, in the Key Vault, select the "Access Policy" pane and click "+ Add Access Policy"

In the "Add access policy" dialog, start by clicking the "Select principal" option. Enter "Microsoft.Azure.Cdn" in the "Select" text input. Click on the "Microsoft.Azure.Cdn" entry so that it shows in the "Selected Members" list half-way down the dialog. Then click the "Select" button.

Back in the "Add access policy" dialog:

• under "Secret Permissions", choose "Get" and "List"
• under "Certificate Permissions", choose "Get" and "List"

Note: The only documentation I could find on this step only mentioned the Secret Permissions -- but it appears the Certificate Permissions were added after that doc was written, and without the cert permissions, the next steps fail. So I'm not 100% certain that the Secret permissions are required, but I do know the certs permissions are.

Now click the "Add" button to save the permissions policy.

Part 5: Associate the Signed Cert with your CDN Endpoint

Difficulty: Easy, if it "Just Works ™"
Time required: Active time: 20 mins. Waiting around time: 12-24 hours, maybe more!

Back in the Azure CDN section of the portal, select the Custom Domains panel and click on the custom domain record that currently says "Disabled" in the Custom HTTPS column.

In the Custom Domain screen, turn on the "Custom domain HTTPS" toggle and pick "Use my own certificate".

In the "Key Vault" dropdown, select your key vault. If you don't see it, then you need to double-check the permissions in the Key Vault Access Policy set in the previous section.

In the "Certificate/Secret" dropdown, pick your cert. The "Certificate/Version" input will auto-populate with the most recent entry for the cert.

Click "Save".

This will kick off the process of enabling the cert for your custom domain. This has two phases:

"Importing Certficate" should take just a few minutes.

"Certificate Provisioning" will take up to 24 hours!!!!!

Each phase will show you the current status and turn to a green checkmark when completed.

Part 7: Point your DNS records to the CDN

Once the Certificate Provisioning is completed, your static website is all set. Now you just need to go into your DNS provider and change the main DNS record for your custom domain to point to your CDN endpoint's address. If your provider allows you to use CNAMEs, use that, otherwise use the actual IP Address of the endpoint and an A record.

If you use Azure for your DNS provider, they provide a shortcut for A and CNAME records where you can select "Alias record set" as "Yes" and then choose "Alias Type" of "Azure Resource". This will then allow you to select the CDN endpoint you created as the source for your DNS entry. This ensures that if the CDN address ever changes, your DNS record changes with it.

ALL DONE!

That's it. You're all done.

When you push changes to your static website, the CDN will continue to serve up the old copy until the cache expires. You can force it to purge the cache in the CDN section of the portal by clicking the "Purge" button for the endpoint or the whole CDN instance:

As I've been giving my Mocking .NET Without Hurting It's Feelings talk, I've referenced several mocking frameworks, but only really gave code examples for a couple of them. In part, this was because more than that would make the presentation chaotic, but also because I had only a very limited exposer (if any) to some of the frameworks.

So I decided to put together a GitHub repository where I implemented the same basic tests using different mocking frameworks in order to a) provide side-by-side examples of how to use the frameworks and b) go a little deeper with some of the frameworks I haven't used much.

While I had no problems with the frameworks I've used (Moq, RhinoMocks, etc), when it came time to write real code using Microsoft Fakes, I quickly ran into a wall. A key feature of the frameworks I've used is the ability to verify a specific mock/stub was or was not called. Generally, this is done through some sort of AssertWasCalled() or AssertWasNotCalled() helper. But for Fakes, this just didn't exist. The functionality is there, but getting to it is like walking barefoot through fire.

Seriously, in order to do something like AssertWasCalled, you need to first include a StubObserver when you create your stub, which will capture calls and other info:

var myMock = new StubIFoo {InstanceObserver = new StubObserver()};

Then, to determine if a method was called, you have to inspect that observer:

Assert.IsTrue(((StubObserver)myMock.InstanceObserver).GetCalls().Any(call => call.StubbedMethod.Name == "MyMethod"));

And if you want to check if specific arguments were passed in, then it get's worse:

 var myCall = ((StubObserver)myMock.InstanceObserver).GetCalls().First(call => call.StubbedMethod.Name == "MyMethod");
 object[] argsToMyCall = myCall.GetArguments().ToArray();

Now I've got an un-typed object array to walk through and check. Eek!

After a couple of hours of internet research and stale Stack Overflow posts, I landed on a NuGet package called Fakes.Contrib which did all the heavy lifting for you and allowed you to add .AsObservable() to your stub, then call .AssertWasCalled as you would expect. It even provided type placeholders so you could do With.Any<MyClass>() if you didn't care about a specific argument. This was exactly what I wanted (and what I would have expected Microsoft to have provided out-of-the-box).

// Arrange
var obj = new MyClass();
var stub = new StubIMyComponent().AsObservable();
var sut = MakeSut(stub);

// Act
sut.DoSomething(obj);

// Assert
stub.AssertWasCalled(mock => mock.MyMethod(With.Any<MyClass>()));

Now, I quickly ran into an issue: The Fakes.Contrib logic only worked on concreate classes. It didn't support using Interfaces, which my whole sample project was built with. But wait! It's Open Source! So I put together a pull request to add support for interfaces and reached out to the project owner Fabian Vilers to let him know it was coming. Fast forward a couple of weeks, and now I'm the primary owner of that project!

I'm not sure yet where this will go. I will add support here and there as I play with Microsoft Fakes, but since I don't have a project where I would use it extensively, I'm hoping to hear from people how do and get some feedback. If nothing else, it gives me some entry-level experience managing an open source project / nuget package.

You can checkout the Fakes.Contrib project on GitHub:

Or on NuGet.org:

Mocking frameworks can be extremely useful for stubbing out objects in your unit tests to ensure you're only testing what you want to test and to allow you to control the environment/state/surroundings under which your tests execute. There are many different mocking frameworks available for use in .Net, each with their own variations on syntax and approach. There are two main categories of mocking frameworks, Constrained and Unconstrained, and I describe how each works in my post How .Net Mocking Frameworks Work Under the Hood.

This post is broken into several sections, starting with a general overview and then hitting on several specific use cases of interest:

• Mock Options
• Stubs vs Mocks
• Using Mocks to Limit the Scope of Your Tests
• General Framework Usage
  • Creating a Mock
  • Controlling Mock Behaviors
  • Change How Many Times to Use the Mock
  • Returning Prepared Values Based on the Input Values
  • Returning the Prepared Values Regardless of the Input Values
  • Advanced Argument Constraints
  • Providing a Method Implementation / Using the Input Params
  • Mocking Things Other Than Methods
  • Throwing an Exception Instead
• Testing Non-Public Members

Mock Options

Most .Net mocking frameworks support three basic types of mock objects:

Strict Mock

A strict mock requires you to provide alternate implementations for each method/property that is used on the mock. If any methods/properties are used which you have not provided implementations for, an exception will be thrown.

Dynamic Mock

With a dynamic mock, any methods/properties which are called by your tests for which you have not provided an implementation will return the default value for the data type of the return value.  In other words, you'll get back a 0 for number types, false for Booleans and a null for any object types.

Partial Mock

A partial mock will use the underlying object's implementation if you don't provide an alternate implementation.  So if you're only wanting to replace some of the functionality (or properties), and keep the rest, you'll want to use this.  For example, if you only want to override the method IsDatabaseActive(), and leave the rest of the class as-is, you'll want to use a partial mock and only provide an alternate implementation for IsDatabaseActive(). (This type of mock is not valid for interfaces.)

IMPORTANT: Constrained mocking frameworks can only mock/stub virtual or abstract members of a real class, so make sure the members you care about are virtual -- OR, event better, mock/stub an Interface, in which case you can do whatever you want. (See my post How .Net Mocking Frameworks Work Under the Hood for more details.)

Stubs vs Mocks

A stub is simply an alternate implementation. A mock, however, is more than that. A mock sets up an expectation that

• A specific method will be called
• It will be called with the provided inputs
• It will return the provided results

The distinction between the two has lead to a fair amount of confusion over time, so not all frameworks differenciate between the two, and even some that do (like RhinoMocks) blur the lines a bit. Some framework have choosen to only support Mocks in order to reduce confusion. Some give them differnt names, such as "Fakes", "Substitute", or "Shim".

In addition to setting up an alternate behavior for when the code is run, the frameworks also provide a mechanism for verifying members were/were not called during execution. For example, RhinoMocks provides a .VerifyAllExpectations() method to ensure all Mocks were called, as well as .AssertWasCalled(...) and .AssertWasNotCalled(...) methods to validate specific members were/were not used during the exectution.

Since mocking frameworks are intended for use within unit testing frameworks, Exceptions are used to signal when your code has violated the expectations. For instance, if you've created a strict mock and your code attempts to use a method that hasn't been specifically mocked, an exception will be thrown. Or, if you utilize one of the post-execution validation methods to check if a member was/wasn't used, an exception will be thrown if your expectations weren't met.

For example, the below test using RhinoMocks will fail due to an ExpectationViolationException being thrown since Expect(101) is not being called.

[Test]
public void TestExpectations()
{
    //Arrange
    int myRecordId = 100;
    var recordFromDatabase = new ImportantData
                                    {
                                        Name = "Orignal Name",
                                        RecordId = myRecordId
                                    };

    var mockDAO = MockRepository.GenerateMock<IDataAccess>();

    mockDAO.Expect(dao => dao.GetRecordFromDatabase(101))
            .Return(recordFromDatabase);

    var fancyBL = new FancyBusinessLogic { MyDataAccessObject = mockDAO };
        

    //Act
    fancyBL.GetImportantDataAndUpdateTheName(myRecordId);

    //Assert
    mockDAO.VerifyAllExpectations();
}

Using Mocks to Limit the Scope of Your Tests

Let's say I have a class that I want to test, but it relies on a database object to fetch/update, etc records from the database. I want to test my class in isolation from the database, so I mock the database object's interface, which allows me to control the flow of information within my implementation.  

To achieve this in the code sample below, I generate a stub for the database object's GetRecordFromDatabase() method so that when it's called with the recordId I care about, it will return my prepared value. This removes the dependency on the database layer (which is not even used since I'm mocking an Interface) and ensures my test is controlling the inputs and outputs so I'm getting exactly what I want for my specific test condition.

[Test]
public void TestGetImportantDataAndUpdateTheName()
{
    //Arrange
    int myRecordId = 100;
    var recordFromDatabase = new ImportantData {RecordId = myRecordId};
    var mockDAO = MockRepository.GenerateMock<IDataAccess>();
         
    mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
            .Return(recordFromDatabase);

    var objectUnderTest = new FancyBusinessLogic { MyDataAccessObject = mockDAO };

    //Act
    var myRecord = objectUnderTest.GetImportantDataAndUpdateTheName(myRecordId);

    //Assert
    Assert.AreEqual(myRecord.RecordId, myRecordId);
    Assert.AreEqual(myRecord.Name, "All Your Base Are Belong To Us");
}

General Framework Usage

Each framework has it's own syntax, so for this guide I'm covering the concepts but can't give specific since they variy widely. I've created a few framework-specific pages to help with the syntax of some of the more populate frameworks:

• Using Rhino.Mocks - quick guide to generating mocks and stubs
• A Guide to Moq for Rhino.Mocks Users
• A Guide to NSubstitute for Rhino.Mocks Users

Creating a Mock

To generate mocks, you'll genearlly use a static factory to create the specific type of mock you want (strict, dynamic or partial). There are typically generic methods such as the following (from RhinoMocks):

• GenerateMock<T> (for DynamicMocks)
• GeneratePartialMock<T>
• GenerateStrictMock<T>

where the T is the class/interface being mocked. Some frameworks will allow you differenciate between mocks and stubs at this time as well, but most do that on a member-by-member basis. The contructor parameters, if you need to provide any, will generally be passed as parameters to this factory method.

For some frameworks the return type directly implements the type you're mocking and the configuration of the mock (see below) is done via extention methods off that type. In other cases, such as Moq, the type returned is a specific type defined by the framework and the actual mocked type is a property on that object. For example, in the case of Moq, you have to use mock.Object to access the mock itself.

Controlling Mock Behaviors

In this section, I'll describe some of the basic things you can do to configure mocks and stubs that are available in all the mocking frameworks. Some frameworks, particularly the Unconstrained types, provide addition functionality beyone these, so make sure to get up to speed on the specific framework you've selected.

Almost all frameworks you a fluent-style builder pattern when configuring your mocks. This means you chain a set of method calls together to build out how you want the mock to work.

First and foremost, for frameworks that differenciate between mocks and stubs, you will need to start your configuration by stating if it's a mock or a stub (see the "Mocks vs Stubs" section above for the difference). Usually that with a .Mock(...), Expect(...) or .Stub(...) method, but the names vary greatly. Frameworks that don't differenciate between mocks and stubs will have a Setup(...), or Fake(...) method. The parameter to these methods is generally a delegate/lambda express for the member being mocked, like this: mock.Stub(x => x.MyFavoriteMethod()).

The primary configuration you'll provide for a mock is the return value. This is usually done via a method named Return(...), to which you provide the value you want returned from the mocked implementation. For example: mock.Mock(x => MyFavoriteMethod()).Return(false).

Change How Many Times to Use the Mock

Once you've setup the mock, you can change how many times it applies in the event your code calls the mocked member more than once. For many, but not all, frameworks, setting up a mock will will cause the mock object to return the provided value the first time it's called with the provided inputs.  Sometimes we want to change this behavior, so the frameworks provide mechanisms to adjust how many times the mock should be used. Note that with a mock, you're potentially setting up expectations for how many times it will be called.

In most frameworks, there's some sort of "Repeat" option you can use, such as these from RhinoMocks: .Repeat.Any(), .Repeat.Once(), .Repeat.Times(10).

mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
        .Repeat.Any()
        .Return(recordFromDatabase);

You may also have a Repeat.Never() option, which will set the expectation the member is never called.

Returning Prepared Values Based on the Input Values

When setting up a mock or stub for a method that takes parameters, the default behavior is to only trigger the mocked behavior when the input exactly match the input you used when configuring the mock. So if you define the mock like this: mockDAO.Stub(dao => dao.GetRecordFromDatabase(100)).Return(null), then this mock will only be used when the input value is 100. All other values will act as if the mock was not configured.

This allows you to have different mocked behanviors based on different inputs. So input 100 could return a valid record, while input 200 would return null or throw an exception.

Returning the Prepared Values Regardless of the Input Values

Sometimes you want a mock to apply regaurdless of the input values, and the frameworks provide various mechanisms to do that. The typical case is for you to provide something in the method when defining the mock (so that it knows which method overload you want to mock) and then apply a modifier like .IgnoreArguments(). This will apply the mock for any input.

mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
          .IgnoreArguments()
          .Return(recordFromDatabase);

Advanced Argument Constraints

Other times you don't want to be so all-or-none in your configurations, so all of the frameworks provide ways to be much more granular in your argument matching configurations, allowing you to provide very detailed conditions for when to use your return values by defining per-parameter constraints. For example, here I've used RhinoMocks syntax to stipulate any input greater than 0 should use this stub.

mockDAO.Stub(dao => dao.GetRecordFromDatabase(Arg<int>.Is.GreaterThanOrEqual(0)))
       .Return(recordFromDatabase);

Here's an example with more than one parameter: (There's a lot more than this – IntelliSense is your friend)

mockDAO.Stub(dao => dao.GetRecordFromDatabase(
                    Arg<int>.Is.GreaterThanOrEqual(0),
                    Arg<decimal>.Is.NotEqual(2.0),
                    Arg<List<string>>.List.ContainsAll(new List<string> {"foo", "bar"}),
                    Arg<object>.Is.NotNull,
                    Arg<object>.Is.Anything))
        .Return(recordFromDatabase);

Many frameworks allow you to provide a delegate that gets called and returns true/false as to if the parameter meet the critera for the mock. This allows you to maintain your own state and get very complex in your handling. Beware: The more complex you get, the more difficult it is for future maintainers to understand what you're attempting to test and is a codesmall that maybe your code is doing too much and should be simplified.

Providing a Method Implementation / Using the Input Params

Instead of just providing a simple value to return, you can provide a full implementation of the method, typically as a delegate/lambda function. This also allows you to get access to the input parameters.  If you want, you can define a delegate and just call the delegate.  I prefer to use lamdas unless the method is really long.

So instead of my previous stub for GetRecordForDatabase which pre-configured a return value, I can do it on the fly, such as this example using RhinoMock's .Do(...) syntax:

mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Do((Func<int, ImportantData>)(input => new ImportantData{RecordId = input}));

Mocking Things Other Than Methods

You're not restricted to just mocking methods. You can mock properties (both getters and setters, though the setter syntax is generally not as straight forward) and events. Some Unconstrained frameworks may also allow you mock constructors, as well as static members of classes.

Throwing an Exception Instead

Instead of returning a value, you can use instruct the mock to force an exception, usually with a .Throw(...) method, like this:

mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
        .IgnoreArguments()
        .Repeat.Any()
        .Throw(new NullReferenceException());         

Testing Non-Public Members

With Constrained frameworks, you can't mock private or protected members, but you can mock internal members if you do a little extra work.

Most of the popular open-source constrained frameworks utilize Castle DynamicProxy to generate an assembly at runtime with the mock logic (see my post How .Net Mocking Frameworks Work Under the Hood for more details). Specifically, you must allow your test assembly and the proxy assembly to access internal members of the assembly under test.  This means adding two InternalsVisibleToAttributes to the AssemblyInfo.cs file of the assembly under test: one for the unit test assembly and one for Castles' DynamicProxyGenAssembly2.  If you're using signed assemblies, you must put the full public key in the attribute.

You can get the public key for an assembly by using the sn -Tp yourAssembly.dll command in the Visual Studio Command Prompt.

For example: (no wrapping -- can't be any spaces in the public key)

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]
[assembly: InternalsVisibleTo("jwright.Blog.UnitTesting, PublicKey=00……ec")]

You may also be interested in my posting about Mocking Objects with Restricted Access (internal/private), which has examples of using reflection to manipulate objects that can’t be mocked with Constrained frameworks.

Unit testing has become an accepted part of our lives as .NET programmers. To help focus our tests to only the code we want to validate, Mocking Frameworks are a powerful tool in our toolbox. Like many tools, if you have an understanding of how the tool works under the hood, you can bend it to your will (and also know where it'll break if you bend too much).

In this post, I provide an overview of the two main types of mocking frameworks: constrained frameworks (like RhinoMocks and Moq) and unconstrained frameworks (such as Typemock Isolator and Telerik JustMock). I'll dig into how the two actually do their magic and some of the pros and cons of each approach.

Terms: Constrained vs Uncontrained

A few years back I read The Art of Unit Testing by Roy Osherove, and in one of the chapters he uses the terms "Constrained" and "Unconstrained" to describe the two main types of mocking frameworks, which I feel are excellent names for the two.

Constrained Frameworks

I'll dig into the "why" later in this post, but contstrained frameworks are "constrained" by the rules of class inheritance within .Net. This means the framework must have visibility to the members you want to mock (ie: you can't mock private members) and the ability to override them (ie: you can't mock sealed or non-abstract/non-virtual members).

Unconstrained Frameworks

Frameworks that fall into this category don't have the same limitations as Constrained frameworks and can pretty much mock anything you care to throw at it.

Contrained Frameworks: Class Inheritance On-Demand

Chances are, if you've used mocking frameworks in .Net, you've likely used one in this category. This is because most of them are free and open-source, so their barriers to entry are set pretty low. Frameworks in this category include Moq, RhinoMocks, NSubstitute, and FakeItEasy. In almost all cases, these frameworks use the Castle DynamicProxy library to do the heavy lifting.

The general idea behind contrained frameworks is that a new proxy class is created at runtime that extends the class (or implements the interface) you're mocking, adding code that will check for the mock behaviors, as well as some infrastructure code.

For example, if you have this class:

    public class MyClass
    {
        public virtual int GenerateNumber(){
            return DateTime.Now.Millisecond;
        }
        
        public virtual int GenerateNumber(int floor){
            return floor + DateTime.Now.Millisecond;
        }
    }

You can generate a mock of GenerateNumber() with code like this (using RhinoMocks syntax):

    var mock = MockRepository.GenerateMock<MyClass>();
    mock.Expect(x => x.GenerateNumber()).Return(11);

Conceptually, when this code runs, it would generate a new proxy class that looked something like this:

    public MyClassMock: MyClass
    {
        public override int GenerateNumber() {
            return 11;
        }
    }

Now, imagine you generated a mock with this syntax:

    var mock = MockRepository.GenerateMock<MyClass>();
    mock.Expect(x => x.GenerateNumber(Arg<int>.Is.GreaterThan(10)))
        .Return(11)
        .Repeat.Twice;

The resulting generated code would start to get more complex -- something like this:

    public MyClassMock: MyClass
    {
        private callCounter = 0;

        public override int GenerateNumber(int floor) {
            
            //Check the conditions:
            if (floor > 10) //Arg<int>.Is.GreaterThan(10)
            {
                callCounter++;
                if (callCounter < 2)  //.Repeat.Twice
                {
                    return 11;
                }
            } 
            
            //All other cases, use the real implementation.
            return base.GenerateNumber(floor);            
        }
    }

If you create a strict mock, any unmocked methods would end up with something like this:

    public override int GenerateNumber() {
        throw new NotImplementedException("Not mocked");
    }

Or for a dynamic mock, like this:

    public override int GenerateNumber() {
        return default(int);
    }

But certainly, it ends up being a lot more complicated. For example, since you later will likely want to call mock.VerifyWasCalled(...), the proxy method will need to maintain information about when it was called and what parameters were provided. You as the caller could have multiple mock implementations based on input args, etc, etc. So there's a fair amount of additional logic that goes into these proxies, but you get the general idea.

The main thing to take away is that the proxy objects used to implement the mocks rely on inheritance to put a middle layer between the calling code and the class being mocked. Because of this, only things that can be inherited can be mocked. Classes that are sealed and members that are static or private cannot be mocked. Members that are internal can be mocked, but only if you add an [InternalsVisibleTo(...)] attribute for the proxy assembly. Since almost all of these frameworks use Castle DynamicProxy (which generates an in-memory assembly named "DynamicProxyGenAssembly2"), that would look like this:

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]

Impact on the design of your own classes

In many cases, in order to fully test your own classes and mock the external dependancies, you will find yourself in a situation where you have to make design tradeoffs to allow the member to be mocked. For example, you may need to make something virtual or internal that you would otherwise not expose for modification or use outside the class. So you must make the choice between testablity and usability of the classes. This can be a hard choice to make.

Uncontrained Frameworks: Make Your Own Man-In-The-Middle Attack

While Constrained frameworks must live within the rules of .Net inheritance, Unconstrained frameworks have almost no limitations as to what they can mock. This is because unconstrained frameworks don't create new classes -- instead, they modify the existing code, even if it's not your code, at runtime to inject their own logic.

To do this, they utilize the .Net Profiling APIs. Using these APIs, a "profiler" (in this case, the mocking framework) registers with the .Net CLR so that the CLR executes a callback within the profiler every time the CLR loads a class, compiles a function, etc. These frameworks will then wait for the JITCompilationStarted callback, which the CLR will use just before it JIT-compiles something. The callback can then use the ICorProfilerInfo::SetILFunctionBody to modify the MSIL for the method being JIT-compiled and inject it's own logic.

Frameworks in this category include Telerik JustMock, Typemock Isolator, and Microsoft Fakes. These are all (to the best of my knowledge) closed-source, commercial (licensed) software. Since most of these frameworks are closed-source, and their license do not permit me to decompile their assemblies, I'm making some guesses here as to how they are implemented, but for the purposes of understanding how they work, I believe this is fine.

Going back to our example class:

public class MyClass
{
    public virtual int GenerateNumber(){
        return DateTime.Now.Millisecond;
    }

    public virtual int GenerateNumber(int floor){
        return floor + DateTime.Now.Millisecond;
    }
}

You can generate a mock of GenerateNumber() with code like this (using Typemock Isolator syntax):

    var mock = Isolate.Fake.Instance<MyClass>();
    Isolate.WhenCalled(() => mock.GenerateNumber()).WillReturn(11);

When the MyClass.GenerateNumber() method is being compiled by the CLR JIT-er, it will call into the profiler (in this case, a Typemock Isolator service that is running), which will re-write the code to insert some hooks, like this:

    public MyClass
    {

        private bool _mockWasProvided() 
        {
            // Would determine if a mock was configured
            // for this specific method call or not.
            // This may need to consider argment filters,
            // "Repeat.Once" directives, etc.
            return true; 
        }

        private int _userProvidedMock() {
            // This would be the user-configured
            // mock behavior.
            return 11;
        }

        public virtual int GenerateNumber() {
            
            //START injected code
            if (_mockWasProvided())
            {
                return _userProvidedMock()
            }
            //END injected code
            
            return DateTime.Now.Millisecond;
        }
    }

Just like the examples I provided in the constrained frameworks, this can get pretty complicated, as it needs to deal with advanced input matching filters, capturing data needed to verify calls were actually made using Isolate.Verify.WasCalled(...);, etc.

An important thing to note: In order for these to work, a profiler application must be running and registered with the CLR's Profiler API before any of your code is loaded into the AppDomain, otherwise it will already be JIT'd and your mocks won't be injected. This generally requires a service or application from the mocking framework be installed on the system and running in the background. Since it's basically listening in to every CLR action, this will need to run with elevated privileges, which could represent a security risk. In effect, you are intenationally building your own man-in-the-middle attack against the code you want to mock. This also means you cannot run code that utilizes Unconstrained mocking frameworks unless you have the profiler installed.

Mocking Third-party and Static Code

One big advantage that comes with the Unconstrained frameworks is that you can mock pretty much anything, since the CLR will call into the profiler when any code is being JIT-compiled. This means you can provide mocks for static, sealed, private, etc, members. It also means you can create mocks for Third-party code or even the .Net Framework itself. As you can imagine, you can get yourself into some hot water here. If you provide a mock for a very commonly used .Net framework member and your mock has really bad performance, you're going to have a very negative impact on the performace of everything! For this reason, most of these frameworks don't let you mock out certain very commonly used / high-performance .Net framework code, such as the string constructor.

To put this into concreate examples, think about the ability to mock out calls to DateTime.Now so that you can write unit tests against the code without having to move that into a seperate, mockable (non-private, virtual) method. You could unit test for Leap Year scenarios, end-of-month reports, etc:

  Isolate.WhenCalled(() => DateTime.Now).WillReturn(new DateTime(2016, 2, 29));

Other common scenarios include:

• SharePoint and EntityFramework SDKs
• HttpContext objects in ASP.NET
• classes using the Singleton pattern.

Putting it into Perspective

Constrained frameworks can cover a major portion of most peoples needs, especially for greenfield (new development work) projects and have the major benefit of being free. Unconstrained frameworks can cover just about anything and remove the need to expose parts of your code just so they can be tested. But they can be fairly expensive.

Here's the big breakdown, in table form.

* At the time I wrote this, prices were as follows:

• Telerik JustMock: $399 per developer
• Typemock Isolator: $399 per developer, $990 per 5 build servers
• Visual Studio Enterprise (MS Fakes): $5,999 per developer ($2,569 renewals). MS Fakes is only available as part of VS Enterprise and is not sold seperately.

I've been a big fan of Rhino.Mocks for many years, but the original Rhino.Mocks maintainer (Oren Eini aka Ayende) stated in 2013 that he is no longer maintaining the project and has handed the project over to a new maintainer (Mike Meisinger), but Mike has not been actively maintaining the project. It's effectively dead and very unlikely to support future versions of .NET, including .NET core.

A while back I wrote a Quick Guide to Using Rhino.Mocks and in last week's post, I gave an overview of Moq for Rhino.Mocks Users. While Moq seems to be the current front runner as a Rhino.Mocks replacement, there's another player in town with NSubstitute. So in the same vane as my Moq post, I'm providing a guide to help people make the transition (or at least help with a review) from Rhino.Mocks to NSubstitue.

The format of this post will follow that of the others to help with cross-referencing between them.

Overall, I'm not a big fan of NSubstitute's syntax, as it looks too similar to just calls to the methods themselves, which:

• makes it harder to understand, as the reader must know which calls are setting up stubs and which are real calls.
• makes it much more likely you'll accidentally do the wrong thing and call a real method.

Now, if you're only mocking interfaces, then this wouldn't be an issue -- but rarely do I find a codebase that allows everything to be an interface.

Generating Different Mock Types

By default, NSubstitue's .For<T> method generates something close to a Dynamic mock -- that is, if you don't explicitly provide a return value, it will return the default value for the data type of the return value if it's a value type (0 for numbers, false for bools, empty string for string), but for object types, it's a bit more complicated. From their documentation:

...any properties or methods that return an interface, delegate, or purely virtual class* will automatically return substitutes themselves.

A pure virtual class is defined as one with all its public methods and properties defined as virtual or abstract and with a default, parameterless constructor defined as public or protected.

So it won't return null in those cases. Instead, it creates a new mock of the return type. Otherwise, it will return null.

Be careful, thought -- if you are using a real class (not an interface), it will call the underlying methods if they aren't virtual.

That said, there is the concept of a partial mock using .ForPartsOf<T> -- that is, a mock that can use the underlying object's implementation. However, to prevent calling the real methods for the methods you do want to mock, you must use the syntax described in the Advanced Argument Constraints section below.

There isn't an option to create a Strict mock in NSubstitute, and it looks like there won't ever be one.

Passing Constructor Arguments

If you need to pass arguments to the constructor of the class you're trying to mock, there are overloads to allow you to do that.

Stubs vs Mocks (or not)

The syntax for NSubstitute is a little different than the others. In most cases, there's not an explicit method you call to create the mock/stub -- rather, you basically call the method you want to create a substitue for. Also, there's no distinction between a mock and a stub -- they're all just substitutions. But since they don't create _expectations_, I would classify them as stubs.

You use the .Returns() method to setup the stub. Note that you can provide multiple values to .Returns() which will set up a chain of calls, like this: .Returns(valueForFirstCall, valueForSecondCall, valueForThirdCall). This works for methods and properties.

For Methods:

For Properties:

Unlike Rhino.Mocks, however, if some other code sets the property value to something else, NSubstitute's stub will return the new value, not the value you stipulated in your stub. In other words, NSubstitue's properties will act like regular properties, and your stub just sets an initial value.

Verifying expectations

Since you're not creating expectations with NSubstitute, there are no mass validation options. Instead, you need to check each stub (which, being more explicit, is probably the better route anyway).

For Methods:

For Properties:

Note that for the getter, you must set a variable to the return value to prevent a compiler error.

The WithAnyArgs versions will ignore whatever parameters (for methods) or set values (for properties) you use in your check and will verify against any inputs.

Advanced Argument Constraints

Both frameworks provide ways to put advanced constraints on the arguments that trigger a mock. Below are examples -- you'll need to consult the framework documentation for the full list of available constraints.

Rhino.Mocks

 mock.Stub(dao => dao.GetRecordFromDatabase(
                         Arg<int>.Is.GreaterThanOrEqual(0),
                         Arg<decimal>.Is.NotEqual(2.0),
                         Arg<List<string>>.List.ContainsAll(new List<string> { "foo", "bar" }),
                         Arg<object>.Is.NotNull,
                         Arg<object>.Is.Anything))
                 .Return(recordFromDatabase);

NSubstitute

  substitute.GetRecordFromDatabase(
                         Arg.Is<int>(i => i >= 0),
                         Arg.Is<decimal>(d => d != 2.0m),
                         Arg.Do<int>(x => capturedValue = x ),
                         Arg.Any<object>()))
         .Returns(recordFromDatabase);

Or, to ignore the arguments altogether, use .ReturnsForAnyArgs(). This is similar to Rhino.Mocks' .IgnoreArguments() method.

Providing a Method Implementation / Using the Input Params

For Rhino.Mocks, in order to provide an alternate implementation, you use the .Do() method to provide a delegate. In NSubstitue, you provide a delegate to the .Returns() call.

Rhino.Mocks

  mock.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Do((Func<int, ImportantData>)(input => new ImportantData
                {
                    Name = "Orignal Name",
                    RecordId = input
                }));

NSubstitute

           
            substitute.GetRecordFromDatabase(0)
                      .ReturnsForAnyArgs(input => new ImportantData
                       {
                           Name = "Orignal Name",
                           RecordId = input.ArgAt<int>(0)
                       });

Throwing an Exception Instead

If the return type of the method is not void, you just provide a delegate to .Returns() that throws an exception. However, if the return type is void, then you use a .When().Do() syntax instead:

Testing Non-Public Members

With Rhino.Mocks, you can’t mock private or internal members, but you can mock internal members if you add an InternalsVisibleTo attribute for the Castle dynamic proxy assembly. NSubstitute also uses the same proxy, so you'll still need to add the attribute. See the Moq Quickstart Guide for details on how to do this.

I've been a big fan of Rhino.Mocks for many years, but the original Rhino.Mocks maintainer (Oren Eini aka Ayende) stated in 2013 that he is no longer maintaining the project and has handed the project over to a new maintainer (Mike Meisinger), but Mike has not been actively maintaining the project. It's effectively dead and very unlikely to support future versions of .NET, including .NET core.

Moq (pronounced "Mock") has become the de facto replacement.

This post hopes to serve as a guide for people making the transition from Rhino.Mocks to Moq.

One big difference between Rhino.Mocks and Moq is what gets returned when you generate the mock and how you operate against it. With Rhino.Mocks, the MockRepository returns to you an instance of the type you're mocking and you apply the mock operators (.Stub(), .Expect(), .VerifyAllExpectations(), etc) directly to that mocked object. Moq, on the other hand, creates a wrapper object that contains a reference to the mocked type.

So in this example, I'm creating an mock of IFoo. For Rhino.Mocks, I get back an IFoo object, but Moq returns a Mock<IFoo> and to get the IFoo object, you access it with the .Object property.

When using Moq, if you have a reference to the mocked object, you can get back to the wrapper object with this helper method: Mock<IFoo> mockWrapper = Mock.Get(mockedObject);

Generating Different Mock Types

For those of you that read my Using Rhino.Mocks Quick Guide, you may recall there are three types of mocks that can be generated by Rhino.Mocks:

Strict Mock

A strict mock requires you to provide alternate implementations for each method/property that is used on the mock. If any methods/properties are used which you have not provided implementations for, an exception will be thrown.

Dynamic Mock

With a dynamic mock, any methods/properties which are called by your tests for which you have not provided an implementation will return the default value for the data type of the return value.  In other words, you'll get back a 0 for number types, false for Booleans and a null for any object types.

Partial Mock

A partial mock will use the underlying object's implementation if you don't provide an alternate implementation.  So if you're only wanting to replace some of the functionality (or properties), and keep the rest, you'll want to use this.  For example, if you only want to override the method IsDatabaseActive(), and leave the rest of the class as-is, you'll want to use a partial mock and only provide an alternate implementation for IsDatabaseActive().

Note that Moq uses the term "Loose Mock" for the Dynamic mock concept. Both frameworks default to Dynamic\Loose mocks.

Here's how you generate the same concepts in Moq:

I'm not a fan of this syntax, because it lets you mix methods in ways that don't make sense, like a strict mock that calls it's base methods: Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>(MockBehavior.Strict) { CallBase = true };. It's not clear what will happen in this scenario if I call a method I haven't explicitly mocked, because using two different inputs (a constructor argument and a property) to represent competing concepts leads to confusion. That said, I can tell you what happens: The Strict setting takes precedent and a runtime exception is thrown:

Moq.MockException : Class1.GetFoo() invocation failed with mock behavior Strict. All invocations on the mock must have a corresponding setup.

Passing Constructor Arguments

If you need to pass arguments to the constructor of the class you're trying to mock, there are overloads to allow you to do that.

Stubs vs Mocks

Again, from my Using Rhino.Mocks Quick Guide, you may recall that:

A stub is simply an alternate implementation. A mock, however, is more than that. A mock sets up an expectation that

• A specific method will be called
• It will be called with the provided inputs
• It will return the provided results

In Rhino.Mocks, you used the .Stub() and .Expect() extension methods to generate your stubs and mocks directly off your mock object. Moq, on the other hand, uses the .Setup() method on the wrapper object to create both. By default, it will create a stub (no expectation), but if you add Verifiable(), it will generate the expectations (thus, becoming a mock).

For both frameworks, you can explicitly verify stubs, but if you want to do mass verification, you must create the expectations up front.

For Methods:

Properties are a different story. In Moq, in addition to Mocks that carry expectations, you can generate stubs for properties that basically allow the properties to be set and have them return the values when the getter is called. You can do this for individual properties (and optionally provide an initial value) or you can do it for all properties with a single call using .SetupAllProperties().

Rhino.Mocks, on the other hand, doesn't provide the ability to track property values, so to get that same functionality, you'd need to use a callback (.Do() or .Callback()) and track the value yourself.

For Properties:

Verifying expectations

The concepts here are pretty similar. You can verify individual call patterns, or (if you created a Mock and not a Stub) you can verify all of the expectations you created in a single pass.

For Methods:

For Properties

Mass Verification

Moq can do mass verification in two ways. If you have created a mock that sets up expectations using .Expect() in Rhino.Mocks or .Verifiable() in Moq, you can use Moq's .Verify() method to validate just those expectations. Moq also provides a .VerifyAll() method which will validate all of the mocks and stubs you've created with .Setup().

Controlling Mock Behaviors

Here are some of the general behavior modifications in Rhino.Mocks and their Moq equivalents:

Advanced Argument Constraints

Both frameworks provide ways to put advanced constraints on the arguments that trigger a mock. Below are examples -- you'll need to consult the framework documentation for the full list of available constraints.

Rhino.Mocks

 mock.Stub(dao => dao.GetRecordFromDatabase(
                         Arg<int>.Is.GreaterThanOrEqual(0),
                         Arg<decimal>.Is.NotEqual(2.0),
                         Arg<List<string>>.List.ContainsAll(new List<string> { "foo", "bar" }),
                         Arg<object>.Is.NotNull,
                         Arg<object>.Is.Anything))
                 .Return(recordFromDatabase);

Moq

 mockWrapper.Setup(dao => dao.GetRecordFromDatabase(
                         It.Is<int>(i => i >= 0),
                         It.Is<decimal>(d => d != 2.0m),
                         It.IsRegex("[a-d]+"),
                         It.IsNotNull<object>(),
                         It.IsAny<object>()))
         .Return(recordFromDatabase);

Providing a Method Implementation / Using the Input Params

For Rhino.Mocks, in order to provide an alternate implementation, you use the .Do() method to provide a delegate. In Moq, the .Returns() method has an overload that lets you provide a delegate.

Rhino.Mocks

  mock.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Do((Func<int, ImportantData>)(input => new ImportantData
                {
                    Name = "Orignal Name",
                    RecordId = input
                }));

Moq

            mockWrapper.Setup(dao => dao.GetRecordFromDatabase(It.IsAny<int>()))   
                .Returns((Func<int, ImportantData>)(input => new ImportantData
               {
                   Name = "Orignal Name",
                   RecordId = input
               }));

Throwing an Exception Instead

This is pretty much a drop-in replacement when creating the mock/stub. Where Rhino.Mocks uses .Throw() for this purpose, Moq uses .Throws();

Testing Non-Public Members

With Rhino.Mocks, you can’t mock private or protected members, but you can mock internal members if you add an InternalsVisibleTo attribute for the Castle dynamic proxy assembly. Moq also uses the same proxy, so you'll still need to add the attribute, but Moq has the added benefit of being able to mock protected members. See the Moq Quickstart Guide for details on how to do this.

In this post, I describe how to create class instances and access/set members from other assemblies when their access levels are set to internal or private.

When unit testing, you often need to generate instances of your domain objects within your tests.  Hopefully, these object implements an interface you can mock with Rhino.Mocks (or your preferred mocking tool), or if not, provide virtual members that can be overridden in a derived class by a mocking tool.  But sometimes, you run into a nasty class that makes your life difficult.  I ran into this recently with the MS Dynamics 2011 SDK, where the Entity class, which drives most of the domain objects in the SDK, does not provide an interface, has internal-only setters on it's properties and has an internal-only constructor. And since Rhino.Mocks can't/won't mock non-virtual members, setting values to what you need for your tests is impossible without some work.

Luckily, you can get around internal and private access restrictions using reflection.

Note: I'll post the full set of classes, including some unit tests, at the end of this post, so in my examples here, I'm not going to include the using statements, etc.

Update 5/2/2012: Added Non-Public Fields section; Added base class recursive lookup for private fields/properties.

Non-Public Constructors:

So, let's start with the constructor, since you'll need an object to work with. The issues to deal with here is finding the right constructor based on the parameter list, so I'll use the Type.GetConstructor method.

public static T CreateInstance<T>(params object[] args)
{
    Type typeToCreate = typeof(T);

    Type[] parameterTypes = args.Select(arg => arg.GetType()).ToArray();

    // Use reflection to get the ConstructorInfo object that matches our parameters
    // even if it's not public.
    ConstructorInfo constructorInfoObj = typeToCreate.GetConstructor(
            BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic, 
            null, parameterTypes, null);

    return (T) constructorInfoObj.Invoke(args);
}

To use it, you need only make a call like this:

var entity = MockingHelper.CreateInstance<ClassWithPrivateConstructors>(param1, param2);

Non-Public Properties:

Ok, now you want to set the value of a property where the setter is non-public.  For this, I have a helper method that takes in the name of the property you want to set as a string, however I highly suggest you use the technique I suggested in my previous post for using reflection to get that string, thus limiting your risk of renaming the actual property and breaking your unit tests. This won't work, however, if the member you're trying to reach isn't visible to you, so you may have to resort to string-based names. (see unit tests at end of this post for full examples)

Note that if a member is private and is defined in a base class (ie: not the Type you're actually working with, but one of it's parent types), then you have to recursively walk the type hierarchy until you find what you're looking for.

public static void SetPropertyValue(object target, string memberName, object newValue)
{
    PropertyInfo prop = GetPropertyReference(target.GetType(), memberName);
    prop.SetValue(target, newValue, null);
}

private static PropertyInfo GetPropertyReference(Type targetType, string memberName)
{
    PropertyInfo propInfo = targetType.GetProperty(memberName,
                                          BindingFlags.Public |
                                          BindingFlags.NonPublic |
                                          BindingFlags.Instance);

    if (propInfo == null && targetType.BaseType != null)
    {
        //if the member isn't actually on the type we're working on, rather it's
        //defined in a base class as private, it won't be returned in the above call,
        //so we have to walk the type hierarchy until we find it.
        // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

        return GetPropertyReference(targetType.BaseType, memberName);

    }
    return propInfo;
}

public static string GetPropertyName<T>(Expression<Func<T>> property)
{
    LambdaExpression lambdaExpression = (LambdaExpression)property;
    var memberExpression = lambdaExpression.Body as MemberExpression ?? 
        ((UnaryExpression)lambdaExpression.Body).Operand as MemberExpression;         
    return memberExpression.Member.Name;       
}

To use it, you need only make a call like this:

var entity = new ClassWithPrivatePropertySetter();
var memberName = MockingHelper.GetPropertyName(() => entity.MyString);
MockingHelper.SetPropertyValue(entity, memberName, "New Value");

Non-Public Fields:

Similar to properties, but a different call off Type:

public static void SetFieldValue(object target, string fieldName, object newValue)
{           
    FieldInfo field = GetFieldReference(target.GetType(), fieldName);
    field.SetValue(target, newValue);
}

private static FieldInfo GetFieldReference(Type targetType, string fieldName)
{
    FieldInfo field = targetType.GetField(fieldName,
                                          BindingFlags.Public |
                                          BindingFlags.NonPublic |
                                          BindingFlags.Instance);

    if (field == null && targetType.BaseType != null)
    {
        //if the field isn't actually on the type we're working on, rather it's
        //defined in a base class as private, it won't be returned in the above call,
        //so we have to walk the type hierarchy until we find it.
        // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

        return GetFieldReference(targetType.BaseType, fieldName);

    }
    return field;
}

To use it, you need only make a call like this:

var entity = new ClassWithPrivatePropertySetter();
MockingHelper.SetFieldValue(entity, "_myStringField", "New Value");

Putting It All Together:

This is all good and whatnot, but to really make this clean, I would suggest creating some extension classes, or at least a helper class that will make these easier to call for your domain object, if you're going to do any really extensive testing.  For example, I created these extension methods to allow me to set the internal-only Attributes property on the Dynamics EntityMetadata object. These are pretty simple, but I have others that create the entity (which has an internal-only constructor) and set several properties all in one swoop.

public static void SetAttributesViaReflection( this EntityMetadata entityMetadata,
                                                       AttributeMetadata [] attributes)
{
    SetPropertyValue(entityMetadata, 
                     GetPropertyName(() => entityMetadata.Attributes ),
                     attributes);
}

public static void SetOneToManyRelationshipsViaReflection( 
                               this EntityMetadata entityMetadata, 
                               OneToManyRelationshipMetadata [] relationships)
{
    SetPropertyValue(entityMetadata, 
                     GetPropertyName(() => entityMetadata.OneToManyRelationships ),
                     relationships);
}

Good Luck and happy reflecting!

The Full Source Code:

using System;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;

namespace jwright.blog
{
    internal static class MockingHelper
    {

        public static T CreateInstance<T>(params object[] args)
        {
            Type typeToCreate = typeof(T);

            Type[] parameterTypes = args.Select(arg => arg.GetType()).ToArray();

            // Use reflection to get the ConstructorInfo object that matches our parameters
            // even if it's not public.
            ConstructorInfo constructorInfoObj = typeToCreate.GetConstructor(
                BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic, 
                null, parameterTypes, null);

            return (T) constructorInfoObj.Invoke(args);
        }
  
  

        public static void SetPropertyValue(object target, string memberName, object newValue)
        {
            PropertyInfo prop = GetPropertyReference(target.GetType(), memberName); 
            prop.SetValue(target, newValue, null);
        }

        private static PropertyInfo GetPropertyReference(Type targetType, string memberName)
        {
            PropertyInfo propInfo = targetType.GetProperty(memberName,
                                                  BindingFlags.Public |
                                                  BindingFlags.NonPublic |
                                                  BindingFlags.Instance);

            if (propInfo == null && targetType.BaseType != null)
            {
                //if the member isn't actually on the type we're working on, rather it's
                //defined in a base class as private, it won't be returned in the above call,
                //so we have to walk the type hierarchy until we find it.
                // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

                return GetPropertyReference(targetType.BaseType, memberName);
            }
            return propInfo;
        }

        public static void SetFieldValue(object target, string fieldName, object newValue)
        {
            FieldInfo field = GetFieldReference(target.GetType(), fieldName);
            field.SetValue(target, newValue);
        }

        private static FieldInfo GetFieldReference(Type targetType, string fieldName)
        {
            FieldInfo field = targetType.GetField(fieldName,
                                                  BindingFlags.Public |
                                                  BindingFlags.NonPublic |
                                                  BindingFlags.Instance);

            if (field == null && targetType.BaseType != null)
            {
                //if the field isn't actually on the type we're working on, rather it's
                //defined in a base class as private, it won't be returned in the above call,
                //so we have to walk the type hierarchy until we find it.
                // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

                return GetFieldReference(targetType.BaseType, fieldName);
            }
            return field;
        }


        public static string GetPropertyName<T>(Expression<Func<T>> property)
        {
            LambdaExpression lambdaExpression = (LambdaExpression)property;
            var memberExpression = lambdaExpression.Body as MemberExpression ?? 
                ((UnaryExpression)lambdaExpression.Body).Operand as MemberExpression;         
            return memberExpression.Member.Name;       
        }

    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace jwright.blog
{

    public class ClassWithPrivateConstructors : BaseClassWithPrivateMembers
    {
        private ClassWithPrivateConstructors()
        {
            MyString = "parameterless";
        }

        private ClassWithPrivateConstructors(string stringToUse)
        {
            MyString = stringToUse;
        }

        public string MyString { get; set; }
    }

    public class ClassWithPrivatePropertySetter : BaseClassWithPrivateMembers
    {
        public ClassWithPrivatePropertySetter()
        {
            MyStringProperty = "parameterless";
        }

        public string MyStringProperty { get; private set; }
           
        private string _myStringField;
        public string MyStringFieldWrapper { get { return _myStringField; } }
    }

    public abstract class BaseClassWithPrivateMembers
    {
        private string _privateStringField;
        public string PrivateStringFieldWrapper { get { return _privateStringField; } }
           
        private String PrivateStringProperty { get; set; }
        public string PrivateStringPropertydWrapper { get { return PrivateStringProperty; } } 
    }

}
  
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace jwright.blog
{
    [TestFixture]
    public class UnitTests
    {
        [Test]
        public void VerifyPropertyNamesCorrectlyDetermined()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = MockingHelper.GetPropertyName(() => entity.MyString);
            Assert.That(memberName, Is.EqualTo("MyString"));
        }

        [Test]
        public void VerifyPropertyValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = MockingHelper.GetPropertyName(() => entity.MyString);

            var newValue = "New Value";

            MockingHelper.SetPropertyValue(entity, memberName, newValue);

            Assert.That(entity.MyString, Is.EqualTo(newValue));
        }


        [Test]
        public void VerifyPrivateBaseClassPropertyValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = "PrivateStringProperty";

            var newValue = "New Value";

            MockingHelper.SetPropertyValue(entity, memberName, newValue);

            Assert.That(entity.PrivateStringPropertydWrapper, Is.EqualTo(newValue));
        }
  
        [Test]
        public void VerifyFieldValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = "_myStringField";

            var newValue = "New Value";

            MockingHelper.SetFieldValue(entity, memberName, newValue);

            Assert.That(entity.MyStringFieldWrapper, Is.EqualTo(newValue));
        }

        [Test]
        public void VerifyPrivateBaseClassFieldValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = "_privateStringField";

            var newValue = "New Value";

            MockingHelper.SetFieldValue(entity, memberName, newValue);

            Assert.That(entity.PrivateStringFieldWrapper, Is.EqualTo(newValue));
        }

        [Test]
        public void CreateInstanceTest_NoParams()
        {
            var entity = MockingHelper.CreateInstance<ClassWithPrivateConstructors>();

            Assert.That(entity.MyString, Is.EqualTo("parameterless"));
        }

        [Test]
        public void CreateInstanceTest_WithParam()
        {
            var testString = "a different value";
            var entity = MockingHelper
                             .CreateInstance<ClassWithPrivateConstructors>(testString);

            Assert.That(entity.MyString, Is.EqualTo(testString));
        }
    }
}

After reading my Rhino.Mocks Quick Reference post, a colleague and I had a discussion about the proper way to validate expectations in Rhino.Mocks. Specifically, he questioned if my use of .VerifyAllExceptions() was correct for the ArrangeActAssert syntax, or, as he proposed, is it the "old" syntax, being replaced by the .AssertWasCalled() methods.

Since this is a person I respect, I decided not to smite him and instead took a mental note to do some quick google searches research. Having failed to actually find Ayende's opinion on the matter in the first 5 minutes, I did come across this post, which raised a point I did not realize had forgotten:

In Rhino Mocks, expectations on stubs are not verified; only mocks are verified. If an object is created with GenerateStub instead of GenerateMock, then its VerifyAllExpectations method doesn't do anything. This is non-obvious because the AssertWasCalled and AssertWasNotCalled methods on a stub will behave the way you want them to. In Rhino Mocks, a stub can keep track of its interactions and assert that they happened, but it cannot record expectations and verify they were met. A mock can do both these things. 

So, if you are using a Stub, you must not use .VerifyAllExpectations(), because it will always pass.

Now, one might argue (and many, many on the Internet do argue) that a Stub should not have any expectations, so you shouldn't be calling either method. Stubs are for providing inputs to allow the code under test to run and limit your test to just the code under test, while Mocks are uses to validate behaviour. (they are one of the tests). 

If someone does have a link to Ayende's opinion, please post as a comment or email/tweet me. I'll update this post if I find it.

Update: found this (http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#ExpectExtensionMethod) where it seems Ayende expects people to use either case (ie: he doesn't state here that one is "proper").  I still seem to remember a blog he wrote stating a preference for one over the other, but I haven't yet found it).

This post is a general review of the Rhino.Mocks syntax. While it is intended primarily as a quick reference for myself, I hope anyone who stumbles upon it can also find it useful.

Rhino.Mocks is a .Net mocking framework which is extremely useful for stubbing out objects in your unit tests to ensure you're only testing what you want to test and to allow you to control the environment/state/surroundings under which your tests execute. It is written by Ayende Rahien, the same guy that created nHibernate.  My typical dev unit testing environment would be Visual Studio (C#) + nUnit + Rhino.Mocks. You can either use the nUnit command line tools to run the tests or several good tools that integrate into Visual Studio, such as ReSharper, TestRunner.Net or, my favorite, NCrunch.

For readability, I suggest writing your tests using the Arrange, Act, Assert syntax.

This post is broken into several sections, starting with a general overview and then hitting on several specific use cases of interest:

• Mock Options
• Creating a Mock
• Limiting the Scope of Your Tests
• Stubs vs Mocks
• Controlling Mock Behaviors
• Providing a Method Implementation / Using the Input Params
• Throwing an Exception Instead
• Mocking a Property
• Testing Non-Public Members

The full code for the snippets used in my examples can be found at the end of this posting.

You may also be interested in my posting about Mocking Objects with Restricted Access (internal/private), which has examples of using reflection to manipulate objects that can’t be mocked with Rhino.Mocks.

For additional features, such as raising events in your mock, see the official Rhino.Mocks guide.

Mock Options

Rhino.Mocks supports three basic types of mock objects:

Strict Mock

A strict mock requires you to provide alternate implementations for each method/property that is used on the mock. If any methods/properties are used which you have not provided implementations for, an exception will be thrown.

Dynamic Mock

With a dynamic mock, any methods/properties which are called by your tests for which you have not provided an implementation will return the default value for the data type of the return value.  In other words, you'll get back a 0 for number types, false for Booleans and a null for any object types.

Partial Mock

A partial mock will use the underlying object's implementation if you don't provide an alternate implementation.  So if you're only wanting to replace some of the functionality (or properties), and keep the rest, you'll want to use this.  For example, if you only want to override the method IsDatabaseActive(), and leave the rest of the class as-is, you'll want to use a partial mock and only provide an alternate implementation for IsDatabaseActive().

IMPORTANT: Rhino.Mocks can only mock/stub virtual members of a real class, so make sure the members you care about are virtual -- OR, event better, mock/stub an Interface, in which case you can do whatever you want.

There are also methods for generating Stubs (see “Mocks vs Stubs” section below).

Creating a Mock

To generate mocks, you'll use the static factory Rhino.Mocks.MockRepository. From this factory, you'll create your mock using one of a few generic methods:

• GenerateMock<T> (for DynamicMocks)
• GeneratePartialMock<T>
• GenerateStrictMock<T>

where the T is the class/interface being mocked. The method parameters, if you provide any, will be passed to the object's constructor.

For example:

        var _mockDAO = MockRepository.GenerateMock<IDataAccess>();
        var _mockManager = MockRepository.GenerateStrictMock<IDataManager>(someParam);

As a general rule, I will generate all of my mocks in the test suite [SetUp] method to ensure everything is reset from one test to the next.  You'll see in my test fixture file in the Code Used In Examples section that I have done just that.

Limiting the Scope of Your Tests

Scenario:

I have a BLL object that I want to test, but it relies on a DAL object to fetch/update, etc records from the database. I want to test my BLL object in isolation from the DAL object, so I mock the DAL interface.  

Things to note in this example: I generate a stub for the dao's GetRecordFromDatabase() method so that when it's called with the recordId I care about, it will return my prepared value. This removes the dependency on the DAO layer (which is not even used since I'm mocking an Interface for the DAO) and ensures my test is controlling the inputs and outputs so I'm getting exactly what I want for my specific test condition.

            mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
                   .Return(recordFromDatabase);

Code:

    [Test]
    public void TestGetImportantDataAndUpdateTheName()
    {
        //Arrange
        int myRecordId = 100;
        var recordFromDatabase = new ImportantData
                                     {
                                         Name = "Orignal Name",
                                         RecordId = myRecordId
                                     };

        _mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
                .Return(recordFromDatabase);

        //Act
        var myRecord = _fancyBL.GetImportantDataAndUpdateTheName(myRecordId);

        //Assert
        Assert.AreEqual(myRecord.RecordId, myRecordId);
        Assert.AreEqual(myRecord.Name, "All Your Base Are Belong To Us");
    }

Stubs vs Mocks

A stub is simply an alternate implementation. A mock, however, is more than that. A mock sets up an expectation that

• A specific method will be called
• It will be called with the provided inputs
• It will return the provided results

So when you setup a mock, you use the syntax .Expect() instead of .Stub().  Then, in your asserts, you can do .VerifyAllExpectations() on your mock to ensure reality matched your expectations.

In this example, the test will fail due to an ExpectationViolationException being thrown due to the Expect(101) not being called.

    [Test]
    public void TestExpectations()
    {
        //Arrange
        int myRecordId = 100;
        var recordFromDatabase = new ImportantData
                                     {
                                         Name = "Orignal Name",
                                         RecordId = myRecordId
                                     };

        _mockDAO.Expect(dao => dao.GetRecordFromDatabase(myRecordId))
                .Return(recordFromDatabase);

        _mockDAO.Expect(dao => dao.GetRecordFromDatabase(101))
                .Return(recordFromDatabase);

        //Act
        _fancyBL.GetImportantDataAndUpdateTheName(myRecordId);

        //Assert
        _mockDAO.VerifyAllExpectations();
    }

Update: see my post for more on VerifyAllExpectations vs AssertWasCalled methods Update: found a posting that I think does a good, simple explanation of Mock vs Stub, including a graphic!

Controlling Mock Behaviors

In the above example, I did _mockDAO.Stub().Return().  This will cause the mock object to return the provided value the first time it's called with the provided inputs.  Sometimes we want to change this behavior, thus the following modifiers can be used between the .Stub() and .Return() calls.

Change how many times to use the stub:

Using the .Repeat.Any(), .Repeat.Once(), .Repeat.Times(10) modifiers:

     _mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
             .Repeat.Any()
             .Return(recordFromDatabase);

Return the prepared value regardless of the input value:

Using .IgnoreArguments():

  _mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
          .IgnoreArguments()
          .Return(recordFromDatabase);

Advanced Argument Constraints:

You can provide very detailed conditions for when to use your return values by defining per-parameter constraints. For example, here I've said the input must be greater than 0.

       _mockDAO.Stub(dao => dao.GetRecordFromDatabase(Arg<int>.Is.GreaterThanOrEqual(0)))
               .Return(recordFromDatabase);

Here's an example with more than one parameter: (There's a lot more than this – IntelliSense is your friend)

_mockDAO.Stub(dao => dao.GetRecordFromDatabase(
                         Arg<int>.Is.GreaterThanOrEqual(0),
                         Arg<decimal>.Is.NotEqual(2.0),
                         Arg<List<string>>.List.ContainsAll(new List<string> {"foo", "bar"}),
                         Arg<object>.Is.NotNull,
                         Arg<object>.Is.Anything))
         .Return(recordFromDatabase);

Additionally, you can put constraints on properties of objects used as parameters. For instance, if the input parameter had a bool property "IsSomethingICareAbout" and you only wanted to provide a return value when that property is true, you could do this:

            _mockDAO.Stub(x => x.SomeMethod(myObject))
                    .Constraints(Property.Value("IsSomethingICareAbout", true)
                    .Return("foo");

You can put constraints on the input arguments in the same way:

            _mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                    .Constraints(Is.GreaterThanOrEqual(0))
                    .Return(recordFromDatabase);

And constraints can be chained with boolean operators:

            _mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                    .Constraints(Is.GreaterThanOrEqual(0) && Is.LessThanOrEqual(100) )
                    .Return(recordFromDatabase);

Note: Constraints must be listed in the order of the parameters (ie: the first set of constraints applies to the first parameter, the second set to the second param, and so on).  And a constraint must be provided for each parameter (you can do Is.Anything() as well).

Providing a Method Implementation / Using the Input Params

Instead of using a .Return() with a simple value, you can provide a full implementation of the method using the .Do() method. This also allows you to get access to the input parameters.  If you want, you can define a delegate and just call the delegate.  I prefer to use lamdas unless the method is really long.

So instead of my previous stub for GetRecordForDatabase which pre-configured a return value, I can do it on the fly:

_mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Do((Func<int, ImportantData>)(input => new ImportantData
                                                            {
                                                                Name = "Orignal Name",
                                                                RecordId = input
                                                            }));

Mocking A Property

If you need to mock a property instead of a method, the syntax is pretty much the same:

    [Test]
    public void TestProperty()
    {
        var mockedInterface = MockRepository.GenerateMock<IHasAProperty>();
        mockedInterface.Expect(x => x.StringProperty).Return("fooString");
        Assert.That(mockedInterface.StringProperty, Is.EqualTo("fooString"));
    }

Throwing an Exception Instead

Instead of .Return(), you can use .Throw() to force an exception:

    [Test, ExpectedException(typeof(NullReferenceException))]
    public void TestNeverCallThisMethod2()
    {
        //Arrange
        _mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Throw(new NullReferenceException());
               
        object inputValue = null;

        //Act
        _fancyBL.NullsNotWelcomeHere(inputValue);

        //Assert
        //nothing to do here -- ExpectedException
    }

Testing Non-Public Members

With Rhino.Mocks, you can't mock private or protected members, but you can mock internal members if you do a little extra work.

Specifically, you must allow your test assembly to access internal members of the assembly under test.  This means adding two InternalsVisibleToAttributes to the AssemblyInfo.cs file of the assembly under test: one for the unit test assembly and one for Rhino.Mocks' DynamicProxyGenAssembly2.  If you're using signed assemblies, you must put the full public key in the attribute.

You can get the public key for an assembly by using the sn -Tp yourAssembly.dll command in the Visual Studio Command Prompt.

For example: (no wrapping -- can't be any spaces in the public key)

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]
[assembly: InternalsVisibleTo("jwright.Blog.UnitTesting, PublicKey=00……ec")]

Code Used In Examples

Here are the full code files to use in order to run my example tests:

DataAccessObject.cs

using System;

namespace jwright.Blog
{
    public class ImportantData
    {
        public string Name { get; set; }
        public int RecordId { get; set; }
    }

    public interface IDataAccess
    {
        ImportantData GetRecordFromDatabase(int recordId);
        void NeverCallThisMethod();
    }

    public class DataAccessObject : IDataAccess
    {
        public ImportantData GetRecordFromDatabase(int recordId) 
                                          { throw new NotImplementedException(); }
        public void NeverCallThisMethod() { throw new NotImplementedException(); }
    }

}

FancyBusinessLogic.cs

namespace jwright.Blog
{
    internal class FancyBusinessLogic
    {
        private IDataAccess _dataAccessObject;
        internal IDataAccess MyDataAccessObject
        {
            get { return _dataAccessObject ?? (_dataAccessObject = new DataAccessObject()); }
            set { _dataAccessObject = value; }
        }

        public ImportantData GetImportantDataAndUpdateTheName(int recordId)
        {
            var record = MyDataAccessObject.GetRecordFromDatabase(recordId);
            record.Name = "All Your Base Are Belong To Us";
            return record;
        }

        public void NullsNotWelcomeHere(object input)
        {
            if (input == null) { MyDataAccessObject.NeverCallThisMethod(); }
        }

    }
}

FancyBusinessLogicTest.cs

using System;
using NUnit.Framework;
using Rhino.Mocks;

namespace jwright.Blog
{
    [TestFixture]
    public class FancyBusinessLogicTest
    {
        private IDataAccess _mockDAO;
        private FancyBusinessLogic _fancyBL;

        [SetUp]
        public void SetUp()
        {
            //reset all my objects under test and mocks
            _mockDAO = MockRepository.GenerateMock<IDataAccess>();
            _fancyBL = new FancyBusinessLogic {MyDataAccessObject = _mockDAO};
        }

        //-----
        // Tests will go here
        //-----
    }
}