The library is hosted on GitHub at:

https://github.com/codeprogression-opensource/OptionStrict.oEmbed

As far as I know, there is only one other open-source oEmbed library available for .NET. It is written in VB.NET and is hosted on CodePlex at:

http://oembed.codeplex.com

For the uninitiated:

oEmbed is a format for allowing an embedded representation of a URL on third party sites.

The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.

http://oembed.com

Now, what does that mean?

Third-parties, such as YouTube, Flickr, Hulu, GrooveShark, CNN, etc. have resources that you want to embed on your site.

There are different types of resources you can embed:

• Photo: represents static photos
• Video: represents playable videos
• Link: represents generic data (i.e., a link to the author’s site or downloadable content)
• Rich: any other type not represented above

You send a web request to the API URL of the provider with the url of the resource, and the provider sends you a response with metadata about the resource as well as representations of the resource.

Let’s get a video of the skit SNL’s “Undercover Celebrity Boss” from Hulu.

To get the resource, I need the API and Resource URL’s…

API: http://www.hulu.com/api/oembed.{format}

Resource: http://www.hulu.com/watch/131076/saturday-night-live-undercover-celebrity-boss

Now, if I click on the resource link, I go to Hulu, but I want to embed the video in my site.

To do that, I make a request to Hulu’s oEmbed API, like so:

http://www.hulu.com/api/oembed.json?url=http://www.hulu.com/watch/131076/saturday-night-live-undercover-celebrity-boss&maxwidth=200

That request returns the following (notice how I asked for a specific size):

{
  "duration": 102.7,
  "type": "video",
  "provider_url": "http://www.hulu.com/",
  "embed_url": "http://www.hulu.com/embed/YdmSIZmY6plQhyhHSceW2A",
  "author_name": "NBC",
  "cache_age": 3600,
  "height": 200,
  "width": 115,
  "html": "<object width="200" height="115"><param name="movie"
       value="http://www.hulu.com/embed/YdmSIZmY6plQhyhHSceW2A"></param>
       <param name="flashvars" value="ap=1"></param>
       <embed src="http://www.hulu.com/embed/YdmSIZmY6plQhyhHSceW2A"
        type="application/x-shockwave-flash" width="200" height="115"
       flashvars="ap=1"></embed></object>",
  "air_date": {},
  "title": "Undercover Celebrity Boss (Saturday Night Live)",
  "thumbnail_width": 200,
  "version": "1.0",
  "thumbnail_url":
      "http://thumbnails.hulu.com/265/50037265/148745_145x80_generated.jpg",
  "thumbnail_height": 110,
  "provider_name": "Hulu"
}

To embed this in my page, I just need to add the html embed code I received to my page.

OptionStrict.oEmbed attempts to make this process a little more streamlined, giving you the ability to consume oEmbed streams, as well as provide an oEmbed API endpoint. More to come!

And thanks to the generosity of the AppHarbor team, we were able to raffle off a Reflector license to one of our attendees!

Getting Started with AppHarbor

You can find many blog posts (and videos) detailing the process of getting started with AppHarbor (see below).  But the basic scenario comes down to these steps*:

1. Installing and configuring Git. (I use msysgit and Git Extensions.)
2. Initialize a repository for your application.
3. Deploy your application to AppHarbor. (If you do not have an AppHarbor account yet, feel free to use this referral link.)

* If you prefer to use Mercurial, follow these steps instead.

If you develop .NET web applications and haven’t tried out AppHarbor yet, do so…Now! I did mention the service is free, right?!?

Mimicking AppHarbor Deployment

Disclaimer: The process I am about to describe is informational and not prescriptive. AppHarbor provides much more value than just deployment, and I do not want to detract from that in any way.

If you have read my previous posts, you know that I use TeamCity and Rake for my build server environment. So I thought I would try to mimic the AppHarbor experience using those tools.

In order to follow along you will need to:

1. Install Git on your development workstation and build server
2. Install Ruby on your build server
3. Install TeamCity on your build server
   * If you need to learn how to install and use TeamCity, I posted a series on TeamCity 4.5.
4. Install Web Deployment Tool 2.0 on your build server and IIS web server
5. Start the web deployment service on your IIS web server
   

* For the purposes of the user group presentation and this post, my development workstation, build server, and web server are all on the same machine.

We need to manually provision much of the infrastructure that would be provided for us automatically by AppHarbor, including:

• Configure the web application in IIS
• Set up a bare Git repository
• Configure TeamCity to watch the bare repository (VCS Settings)
• Use customize build scripts in TeamCity (Build runner/task)
• Push your application to the TeamCity repository

Other tasks I will not be considering for this sample include database provisioning and custom configuration variables.

Remember, with AppHarbor, the initial provisioning takes a matter of seconds. With that, let’s get our environment ready.

Configure the web application in IIS

1. Create a folder on your web server to store the website. (e.g., c:\sites\sample)
2. In IIS, create a new virtual directory under the default site and set the path to the folder you just created. My virtual path is sample.
3. Note the IIS application path. Mine is Default Web Site\sample. My url will be http://localhost/sample.

Set up the bare Git repository

1. Create a folder to store your bare repository. This is the repository TeamCity will watch and use to get code to build. You can create the repository on the build server or on a remote server.  (e.g., c:\repos\sample.git\)
2. Right-click the folder and run the Git Bash from the context menu
3. In Git Bash, type git init –bare

Configure the TeamCity build configuration

1. Create a new project (e.g., Sample)
2. Create a new build configuration (e.g., Deploy) and name it
3. Leave all other settings on the first page of the wizard at their default
4. Attach a new VCS and name it
5. Select Git as the VCS type
6. Set the Fetch URL to the bare repository you just created (e.g., c:\repos\sample.git)
7. Leave all other settings at their default
8. Add a new build task
9. Select Rake as the build runner
10. Select Rakefile content and copy the following into the textbox (Update the site path and project names as appropriate)
    

    require 'rubygems'
    require 'erb'
    require 'fileutils'
    require 'find'
    require 'rake'
    require 'rake/tasklib'
    
    task :default do
        package_location="sample/"  # website folder location relative to checkout root
        project_file =  "sample/sample.csproj" # website project location relative to checkout root
        package_name = "website"
        package = "website.deploy.cmd"
     
        destination_site = 'Default Web Site/sample' # Change to match IIS path
        clr_version = 'v4.0.30319' 
        framework_dir = File.join(ENV['windir'].dup, 'Microsoft.NET', 'Framework', clr_version)
        msbuild_file = File.join(framework_dir, 'msbuild.exe')
    
        FileUtils.remove_file("#{package_location}#{package}", true)
        FileUtils.remove_file("#{package_location}#{package_name}.zip", true)
        FileUtils.remove_file("#{package_location}#{package_name}.deploy-readme.txt", true)
        FileUtils.remove_file("#{package_location}#{package_name}.SetParameters.xml", true)
        FileUtils.remove_file("#{package_location}#{package_name}.SourceManifest.xml", true)
    
        # Package website (requires VS2010 version of msbuild)
        sh "#{msbuild_file} \"#{project_file}\" /maxcpucount /nr:true /v:m /T:Clean,Package /P:BuildInParallel=true;WarningLevel=0;Configuration=debug;DeployIisAppPath=\"#{destination_site}\";PackageLocation=#{package_name}.zip"
    
        # Deploy website (requires Web Deployment service running on web server)
        sh "#{package_location}#{package} /M:localhost /Y \"-skip:objectName=dirPath,skipAction=Delete,absolutePath=logs\""
    
    end

    view raw rakefile.rb This Gist brought to you by GitHub.
11. Leave all other settings at their default
12. On the Build Triggering page, add a new VCS trigger to build on a VCS change.

Whew! Now that all the infrastructure is in place, let’s do this!

Push your application to your TeamCity repository

1. Assuming your local Git repository is set up and you’re application is ready to deploy…from Git Bash in your local repo, add your remote repository.  Given the settings described above, I would use the following command: git remote add teamcity /c/repos/sample.git
2. Then type: git push teamcity master
3. In less than a minute, TeamCity should start to package and deploy the website.

Using TeamCity for deployment takes markedly longer than AppHarbor. TeamCity uses a polling interval to determine if there are changes; whereas, I assume AppHarbor is using a git post-commit-hook. As an aside, if you haven’t already, start looking into the Web Deployment Tool.

Auto-provisioning and super-fast deployment on an elastic infrastructure…wish I had implemented it first.

Update:

A bug was introduced in Visual Studio 2010 SP1 which causes an error when deploying with parameters. You may need to update your Microsoft.Web.Publishing.targets file referenced in the KB article (although I cannot confirm that this fixes the problem, yet).

Git is a DVCS, or distributed version control system, that is gaining popularity in the .NET community. In this session, we will explore:

• How Git is different from other version control systems (Subversion, Team Foundation Server, Mercurial)
• Common tools (emphasis on Windows users)
• Basic commands and workflow
• Using Git as your Subversion client
• Various Git services, such as GitHub, and AppHarbor

My slides are available on github.

If you attended the presentation, please leave your feedback at SpeakerRate (http://spkr8.com/t/5760).

Being a .NET shop, the obvious answer would be to head over to Scott Hanselman’s blog and pull up this post: What Great .NET Developers Ought To Know (More .NET Interview Questions).  Scott has broken out what he considered, at the time, to be the relevant platform- and framework-related knowledge required of a .NET developer at various points in their career.

However, I do not believe that knowledge of a programming language and hosting platform solely defines a great developer, no matter the depth or detail of the knowledge.  If a developer is unable to apply that knowledge to a problem domain, it is useless knowledge – a mere parlor trick.

Given a developer has an affinity towards coding and technology, that developer should be able to learn new programming languages, new platforms, and new tools.  If a senior developer in a ASP.NET shop moves to a Ruby shop, what would define him or her as a Senior level? Language syntax and idiomatics should only be a small part of the equation.

A Different Perspective

I believe developer levels are determined by a combination of autonomy, mastery, and trust.  I have a started a list below. This list is not scientific – it just represents my current viewpoint.

Junior Developers

Autonomy: LOW

• Not self-directed
• Need tasks rather than requirements/user stories
• Tasks are expected to be implemented as defined
• Often under the watchful eye of a senior developer
• May need assistance in finding/deriving appropriate solutions

Mastery: LOW->MEDIUM

• Comfortable with the constructs of their main language/platform
• Basic understanding of object-oriented programming
• May have understanding of architectural design patterns and principles (MVC, Single Responsibility Principle)
• Limited comprehension of problem domain
• Can write basic tests/specifications

Trust: LOW

Mid-Level Developers

Autonomy: MEDIUM

• Self-directed
• Can work from user stories
• Can normally find/derive appropriate solutions

Mastery: MEDIUM

• Comfortable with the constructs of their main language and platform
• Basic understanding of constructs of additional languages or platforms
• Moderate understanding of object-oriented programming
• Basic understanding of functional programming
• Basic understanding of messaging architectures
• Understands several design patterns and principles
• Can write both state and interaction tests/specifications
• Comprehends problem domain
• Committed to continuous learning

Trust: MEDIUM

• Can represent the needs of the development team
• Is respected in the community

Senior Developers

Autonomy: HIGH

• Self-directed
• Can develop user stories
• Can elucidate requirements
• Can generally find, derive, or create appropriate solutions

Mastery: MEDIUM->HIGH

• Comfortable with two or more languages/platforms
• Moderate to high understanding of object-oriented and functional programming
• Moderate to high understanding of messaging
• Can explain design patterns and principles to developers, as well as non-technical staff
• Comprehends problem domain and common domain patterns
• Can write state, interaction, integration tests/specifications
• Committed to continuous learning

Trust: HIGH

• Can represent the needs of the development team
• Can represent the needs of the customer
• Can represent the needs of management
• Is respected in the community

Please note that I do have emphasis on language in each level, but language is dwarfed by the need to understand and communicate the problem domain.  Also, mastery of a particular platform is less important than autonomy or trust.

What do you think defines a junior, mid, or senior developer?

If you attended and have any feedback/constructive criticism, please leave a comment!

For those who missed the session – or for those who would like to see it again – you will get another opportunity. I will be presenting this session at NETDUG (in April, I believe).  I am also submitting the session to Portland Code Camp.

Session Assets

As promised, I have included, in an archive:

• The slide deck
• The solution as completed during the session (CodeProgression.BCC2010)

I have also included:

• The solution with which we started (CodeProgression.BCC2010.Start)
• A solution based on a MassTransit sample (from which I based the NServiceBus sample)

Notes about the solutions:

If you are planning on working the NServiceBus sample from scratch, don’t forget to add the NServiceBus.Host.exe as the startup program for each endpoint project.

For the MassTransit solution, you may need to update the references\masstransit\MassTransit.RuntimeServices.exe.config to point to your local database.

Resources

Here is also a list of resources I used while preparing for this session:

NServiceBus
http://www.nservicebus.com
http://gurustop.net/blog/2008/04/20/enterprise-service-bus-messaging-using-nservicebus/
http://elegantcode.com/2009/10/09/exploring-nservicebus/
http://sourceforge.net/apps/mediawiki/nservicebus/index.php?title=Tutorials
http://blog.zoolutions.se/post/2010/02/08/Conquering-NServiceBus-part-1-e28093-Getting-Started.aspx
http://blog.zoolutions.se/post/2010/02/09/Conquering-NServiceBus-part-2-e28093-Initial-configuration.aspx

MassTransit
http://masstransit.pbworks.com/A-First-Look-at-Mass-Transit
http://blogs.dovetailsoftware.com/blogs/kmiller/archive/2009/08/26/producing-and-consuming-messages-using-masstransit-and-structuremap.aspx
http://rhysc.blogspot.com/2009/05/getting-started-with-masstransit.html

TopShelf
http://blogs.dovetailsoftware.com/blogs/kmiller/archive/2010/01/20/configuring-topshelf-using-a-structuremap-container.aspx
http://blogs.dovetailsoftware.com/blogs/kmiller/archive/2010/01/20/controlling-application-lifetime-in-topshelf.aspx

Misc
http://www.enterpriseintegrationpatterns.com
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683

When I see the MSpec code, I think about it being an internal DSL for doing the testing, and I start to think that perhaps it should just go ahead and be it’s own language instead of trying to live inside of C#. On the other hand, I wonder about the value of using another language to unit test C# code…

I think John was spot-on with his instinct – in my opinion, MSpec is an internal DSL.  I also think that is the beauty of the framework.  Domain-specific languages are meant to solve a target problem in a particular domain.  MSpec’s problem domain is testing .NET code.  By convention, it constrains you to its limited language to help you test your code in a meaningful yet powerful manner.

What is an Internal DSL?

According to Martin Fowler:

“Internal DSLs are particular ways of using a host language to give the host language the feel of a particular language…Internal DSLs are also referred to as embedded DSLs or FluentInterfaces”  (from Bliki article: Domain Specific Language)

“Internal DSLs use the same general purpose programming language that the wider application uses, but uses that language in a particular and limited style.”
(from DSL-WIP section: Using Domain Specific Languages)

But, as John wondered, is there value in using another language (external DSL) to test C# code?

Perhaps.  Yet, I believe there is more value in using external DSLs to test user interfaces (e.g., WatiR, WatiN, and Selenium), or for build scripting (e.g.,Rake, psake).

Let’s look at that question a little differently: Is there value in using an internal DSL (like MSpec) to test C# code?

To that I give a resounding YES! MSpec’s host language is C#…which provides great value to me.  I get all the benefits of intellisense, refactoring, and (R#) navigation in my IDE.  I don’t have to worry about the impedance mismatch between my code and an external DSL.

You Probably Use DSLs All the Time

In fact, I use several DSLs every day when I code.

Consider the following table of frameworks. You may not have thought any of these in the context of a domain-specific language, but each has a specific purpose with its own limited language constructs. Some are internal, some external.

When considering a framework within your host language: If the framework has a fluent interface with language devoted to a specific problem domain, it is probably an internal DSL.

So is MSpec an internal DSL? Yes.

And is that okay? Definitely.

Further Reading

Check out Martin Fowler’s articles on domain-specific languages:

http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
http://martinfowler.com/dslwip/UsingDsls.html
http://martinfowler.com/dslwip/InternalOverview.html

From my unscientific observation, developers either love or hate MSpec.  For those that hate MSpec, I wonder if it is the grammatical syntax or the lambda-expression style creating the aversion.  Some even expound MSpec as cryptic and cumbersome.  This seems to be a common complaint – one I hope to address in this post.

I find that those drawn to MSpec have experienced an evolution of testing/specification styles, influenced partially by the community and partially by frameworks they have used.  At the very least, this has been my experience as I have transitioned from xUnit frameworks.

Conventions of MSpec

I particularly like the conventions MSpec encourages using its four delegate types:

Establish:

• Provides setup (context) for the specification
• One per class (but not required)
• “Unlimited” per specification or inheritance chain
• Runs down the inheritance chain prior to the Because delegate

Because:

• The action/event being tested
• One per specification

It:

• An assertion (usually extension methods/fluent interfaces based on NUnit/xUnit Assert classes)
• “Unlimited” per specification/class
• Can be “hosted” in a Behavior class
• Runs after the Because
• Can be reused when placed in a Behavior class
• If body of delegate is missing, will mark as “Ignored” or “Not Implemented” in a test runner

Cleanup:

• Provides teardown for the specification
• One per class (but not required)
• “Unlimited” per specification or inheritance chain
• Runs up the inheritance chain after the It delegates are completed

MSpec also has one other delegate type (Behaves_like<T>) and several optional attributes available (Subject, Tag, Ignore, Behavior).  [Subject] provides additional information about the specification. [Tag] is similar to the [Category] attribute in NUnit.  [Ignore] is self-explanatory. [Behavior] marks a class made up entirely of assertions (It delegates).  Behaves_like<T> is a delegate type that can be included in a specification block taking the place of a set of assertions (It delegates).

NUnit – TestFixture-Per-Class

I have gone from using a TestFixture-Per-Class style to a behavior-driven/context-specification style.  I would like to use the standard HomeController, created in an ASP.NET MVC 1.0 project, as an example class to explore this evolution. 

In my TestFixture-Per-Class days, I may have tested the Index action as follows:

[TestFixture]
public class HomeControllerTests
{
    [Test]
    public void IndexActionTest()
    {
        var controller = new HomeController();
        var result = (ViewResult) controller.Index();
        Assert.AreEqual("Welcome to ASP.NET MVC!", result.ViewData["Message"]);
    }
}

I do like the simplicity of the code.  One line to set up the test, one to execute, and one to assert.  There is a little ceremony involved with marking the class and methods with the NUnit attributes.  With this simple test, it is easy to distinguish the setup code from the assertion; yet, a more complex test would make scanning the test more difficult.  Comments can help, but tend to just add noise.

NUnit – Arrange/Act/Assert

With the advent of BDD, I started naming my classes and expectations as inspired by BDD syntax.  I might have used the [SetUp] attribute or a base class to organize my test code in a style similar to the following:

[TestFixture]
public class when_I_go_to_the_home_page: AAA
{
    private HomeController _controller;
    private ViewResult _result;

    protected override void Arrange()
    {
        _controller = new HomeController();
    }
    protected override void Act()
    {
        _result = (ViewResult)_controller.Index();
    }

    [Test]
    public void then_the_welcome_message_should_be_displayed()
    {
        _result.ViewData["Message"].ShouldEqual("Welcome to ASP.NET MVC!");
    }
}

This actively separates out the different responsibilities of the test.  You can see where the setup code is, as well as the action being tested.  The assertion is the only line of code in the test method.  There is still ceremony involved with the attributes.  Plus, we have added a little more ceremony and noise with the Arrange() and Act() overrides.  This simple test does not necessarily need the parts split in this manner, but it would help with more complex scenarios.  Additionally, the assertion is using extension methods based on the NUnit Assert classes which provides a little more clarity to the assertion.

MSpec

Once started down the path of a behavior-driven (or context/specification) style, I started looking at frameworks devoted to that style.  MSpec is one of those frameworks.  Here is the Index action specification in MSpec:

public class when_I_go_to_the_home_page
{
    Establish context = () =>  _controller = new HomeController();
    Because of = () => _result = (ViewResult)_controller.Index();
    It should_display_the_welcome_message = () => _result.ViewData["Message"].ShouldEqual("Welcome to ASP.NET MVC!"); 

    static HomeController _controller;
    static ViewResult _result;
}

If you look closely, this specification is very similar to the first NUnit test.  However, there are no attributes to specify and the specification has a distinct functional separation.  The Establish/Because/It syntax is analogous to the Given/When/Then language used in user stories or Arrange/Act/Assert syntaxes used in the previous example.  In my opinion, this has less noise than the test using NUnit with an AAA base class – even while using the lambda delegate syntax.

MSpec – SpecificationFor<ClassUnderTest>

I often use a base class to handle some of my setup code. Using StructureMap and RhinoMocks, it generates and injects proxied dependencies for the given class.  In this example, I have no dependencies to wire up, but I think you can still see the benefits.

public class when_I_go_to_the_home_page : SpecificationFor<HomeController>
{
    Because of = () => _result = (ViewResult)ClassUnderTest.Index();
    It should_display_the_welcome_message = () => _result.ViewData["Message"].ShouldEqual("Welcome to ASP.NET MVC!"); 

    static ViewResult _result;
}

The Establish delegate is not needed in this specification, because I have wired up the class via the base class.  I feel this version is most clear and concise of all the examples, and neither cryptic nor cumbersome  If you are interested in the SpecificationFor<T> base class and the supporting components, check out my previous post. 

Looking to the Future

I hope that this post has shown that MSpec does not have to be cryptic, nor cumbersome.  If you considered it as such before, please take another critical look.

Given the evolving state of the craft, I am sure that my test/specification style will continue to gradually change.  I am sure that my framework of choice will eventually change as well, especially as each framework is extended and challenged by others.  Hopefully, you can be open to evolving your style as well.

I have been using StructureMap.AutoMocking with MSpec (Machine.Specifications) and Rhino.Mocks for a few months now.  Although I am very comfortable with the patterns that emerge from using the frameworks together, introducing StructureMap.Automocking to other developers is sometimes challenging.

When viewing a specification or test set up with the Rhino.Mocks or Moq automocking container, what is being tested is not readily apparent.  Once the concept is explained and demonstrated, these same developers seem to have no issue with maintaining the specifications/tests.

I decided to wrap the details of the container to make the intention clearer and explanation easier.  I have started using this wrapper in my projects, and have found it makes building up specifications more efficient in my daily coding.

Let me know whether this is useful to you, or how it could be made more useful.

The Examples

Let’s contrive an example.  We’ll say we have a coffee machine that grinds its own beans before brewing. However, the hopper has to have beans before starting the grind.  Here is the basic specification:

We could start without a container, using Rhino.Mocks to build up the CoffeeMachine dependencies manually:

[Subject(typeof(CoffeeMachine),"using vanilla Rhino.Mocks")]
public class Example01_when_preparing_coffee_grounds
{
    Establish context = () =>
        {
            Grinder = MockRepository.GenerateMock<IGrinder>();
            Hopper = MockRepository.GenerateMock<IHopper>();
            Hopper.Expect(x => x.HasBeans()).Return(true);
            CoffeeMachine = new CoffeeMachine(Grinder, Hopper);
        };

    Because of = () => _coffeeMachine.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

    static IGrinder Grinder;
    static IHopper Hopper;
    static CoffeeMachine CoffeeMachine;
}

For those of you not familiar with the MSpec style, please refer to the following posts:

• Make BDD Your BFF
• Step by Step to Using MSpec (Machine.Specifications) with ReSharper
• MSpec – Take 2
• MSpec BDD framework installer
• Updated! From the Morning Brew #487: BDD with MSpec and Rhino Auto Mocks, parts  1, 2, and 3
  Here is the same specification using the RhinoAutoMocker<T> class provided by StructureMap.AutoMocking:

[Subject(typeof(CoffeeMachine),"using RhinoAutoMocker<CoffeeMachine>")]
public class Example02_when_preparing_coffee_grounds
{
    Establish context = () =>
        {
            CoffeeMachine = new RhinoAutoMocker<CoffeeMachine>();
            Grinder = CoffeeMachine.Get<IGrinder>();
            Hopper = CoffeeMachine.Get<IHopper>();
            Hopper.Expect(x => x.HasBeans()).Return(true);
        };

    Because of = () => v.ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

    static IGrinder Grinder;
    static IHopper Hopper;
    static RhinoAutoMocker<CoffeeMachine> CoffeeMachine;
}

Although I think this looks cleaner, the initialization of CoffeeMachine causes some confusion. Unfortunately, a common question would be, “Is RhinoAutoMocker<CoffeeMachine> creating a mocked version of CoffeeMachine?” Well, not exactly.

RhinoAutoMocker is an implementation of the AutoMocker base class which uses StructureMap to fill dependencies.  The RhinoAutoMocker implementation of the container uses Rhino.Mocks to generate all of dependencies of the target class, whereas the MoqAutoMocker implementation uses Moq.  (Optionally, the target class can be partially mocked in order to further isolate behavior.)  We then retrieve the class under test (in this case, CoffeeMachine) and its dependencies (IGrinder and IHopper) from the container for use.

If you do not need to setup any expectations in the specification, there is no need to retrieve the dependency from the container.  However, in this specification, we need both dependencies.

(Incidentally, I do not like the ClassUnderTest name.  I may end up changing this to Instance, ClassInstance, TargetClass, or something similar.  Suggestions?)

By moving the initialization of the RhinoAutoMocker to a base class, some of the chattiness of the context can be hidden.

[Subject(typeof(CoffeeMachine),"using RhinoAutoMocker base")]
public class Example03_when_preparing_coffee_grounds : with_rhinoautomocker
{
    Establish context = () => Hopper.Expect(x => x.HasBeans()).Return(true);

    Because of = () => CoffeeMachine.ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));

}

[Subject("using RhinoAutoMocker<T>")]
public class with_rhinoautomocker
{
    protected static IGrinder Grinder;
    protected static IHopper Hopper;
    protected static RhinoAutoMocker<CoffeeMachine> CoffeeMachine;

    Establish context = () =>
    {
        CoffeeMachine = new RhinoAutoMocker<CoffeeMachine>();
        Grinder = CoffeeMachine.Get<IGrinder>();
        Hopper = CoffeeMachine.Get<IHopper>();
    };
}

However, we are still initializing and accessing the class in a less than optimal manner.To make the usage of the container a little more seamless, I decided to create a wrapper and factory for the AutoMocker.  Setup of the dependencies and expectations are done through an AutoMocker wrapper object.  The instance of the class under test is accessed through a ClassUnderTest object.

The Result

The specification (and base class) now look like this:

[Subject(typeof(CoffeeMachine),"using coffee machine base")]
public class Example05_when_preparing_coffee_grounds : with_coffee_machine
{
    Establish context = () => Hopper.Expect(x => x.HasBeans()).Return(true);

    Because of = () => ClassUnderTest.PrepareCoffeeGrounds(12);

    It should_check_if_hopper_has_beans = () => Hopper.VerifyAllExpectations();
    It should_grind_coffee = () => Grinder.AssertWasCalled(x => x.Grind(12));
}

[Subject("using SpecificationFor<CoffeeMachine>")]
public class with_coffee_machine : SpecificationFor<CoffeeMachine>
{
    protected static IGrinder Grinder;
    protected static IHopper Hopper;

    public with_coffee_machine
    {
        Grinder = AutoMocker.Get<IGrinder>();
        Hopper = AutoMocker.Get<IHopper>();
    }
}

As you can see, the base class inherits from SpecificationFor<T>.  The default constructor uses Rhino.Mocks(MockMode.AAA) to generate the dependencies.  It then exposes a AutoMocker object, which is just the wrapper around the AutoMocker base class.  It also exposes a ClassUnderTest object.  If I didn’t need to use the dependencies, I could make the Example05_when_preparing_coffee_grounds class inherit from SpecificationFor<CoffeeMachine> instead of inheriting from the base class.

The Code

I have included the code for the wrapper below for your review.  The code and six examples are available on my Google code repository. The repository also includes an example using the MoqAutoMocker.  All the examples have the same assertions, but are built up using the different techniques.

namespace CodeProgression.Framework.Testing
{
    public abstract class SpecificationFor<T> where T: class
    {
        protected static ClassUnderTest<T> Factory;

        // UPDATE 2009-12-21:
        //   Moved initialization here
        protected static T ClassUnderTest {get {return AutoMocker.Instance;} }

        protected SpecificationFor()
        {
            AutoMocker = AutoMockFactory.CreateTarget<T>();

            // UPDATE 2009-12-21:
            //    Initializing here prevented injected dependencies!
            // AutoMocker.PartialMockTheClassUnderTest();
            // ClassUnderTest = AutoMocker.Instance;
        }

        protected SpecificationFor(AutoMockType type)
        {
            AutoMocker = AutoMockFactory.CreateTarget<T>(type);

            // UPDATE 2009-12-21:
            // Initializing here prevented injected dependencies!
            // AutoMocker.PartialMockTheClassUnderTest();
            // ClassUnderTest = AutoMocker.Instance;
        }
    }

    public static class AutoMockFactory
    {
        public static ClassUnderTest<TARGETCLASS> CreateTarget<TARGETCLASS>() where TARGETCLASS : class
        {
            return CreateTarget<TARGETCLASS>(AutoMockType.RhinoMocksAAA);
        }

        public static ClassUnderTest<TARGETCLASS> CreateTarget<TARGETCLASS>(AutoMockType framework) where TARGETCLASS : class
        {
            AutoMocker<TARGETCLASS> mocker;
            ServiceLocator serviceLocator;
            switch (framework)
            {
                case AutoMockType.RhinoMocksAAA:
                    mocker = new RhinoAutoMocker<TARGETCLASS>(MockMode.AAA);
                    serviceLocator = new RhinoMocksAAAServiceLocator();
                    break;
                case AutoMockType.RhinoMocksClassic:
                    mocker = new RhinoAutoMocker<TARGETCLASS>(MockMode.RecordAndReplay);
                    serviceLocator = new RhinoMocksClassicServiceLocator();
                    break;
                case AutoMockType.Moq:
                    mocker = new MoqAutoMocker<TARGETCLASS>();
                    serviceLocator = new MoqServiceLocator();
                    break;
                default:
                    throw new ArgumentOutOfRangeException("framework");
            }
            return new ClassUnderTest<TARGETCLASS>(mocker, serviceLocator);
        }
    }

    public enum AutoMockType
    {
        Moq,
        RhinoMocksAAA,
        RhinoMocksClassic
    }

    public class ClassUnderTest<TARGETCLASS> where TARGETCLASS : class
    {
        readonly IAutoMocker<TARGETCLASS> _mocker;
        readonly ServiceLocator _serviceLocator;

        public ClassUnderTest(IAutoMocker<TARGETCLASS> mocker, ServiceLocator serviceLocator)
        {
            _mocker = mocker;
            _serviceLocator = serviceLocator;
        }

        public AutoMockedContainer Container
        {
            get { return _mocker.Container; }
        }

        public TARGETCLASS Instance
        {
            get { return _mocker.ClassUnderTest; }
        }

        public void MockObjectFactory()
        {
            _mocker.MockObjectFactory();
        }

        public void PartialMockTheClassUnderTest()
        {
            _mocker.PartialMockTheClassUnderTest();
        }

        public T Get<T>() where T : class
        {
            return _mocker.Get<T>();
        }

        public void Inject(Type pluginType, object stub)
        {
            _mocker.Inject(pluginType, stub);
        }

        public void Inject<T>(T target)
        {
            _mocker.Inject(target);
        }

        public T AddAdditionalMockFor<T>() where T : class
        {
            return _mocker.AddAdditionalMockFor<T>();
        }

        public void UseConcreteClassFor<T>()
        {
            _mocker.UseConcreteClassFor<T>();
        }

        public T[] CreateMockArrayFor<T>(int count) where T : class
        {
            return _mocker.CreateMockArrayFor<T>(count);
        }

        public void InjectArray<T>(T[] stubs)
        {
            _mocker.InjectArray(stubs);
        }

        public T Mock<T>() where T : class
        {
            return _serviceLocator.Service<T>();
        }
        public object Mock(Type serviceType)
        {
            return _serviceLocator.Service(serviceType);
        }
        public T PartialMock<T>() where T : class
        {
            return _serviceLocator.PartialMock<T>();
        }
    }
}

My original classes were similar to this:

public class MyProgress{
   public virtual Guid Id { get; set; }
   ...
   ...
   public virtual MyStatus Status { get; private set; }
}

public enum MyStatus{
   New,
   InProgress,
   Completed,
   Canceled,
   Failed
}

My new state pattern was similar to this:

public abstract class MyStatus
{
    public static readonly MyStatus New = new NewStatus();
    public static readonly MyStatus InProgress = new InProgressStatus();
    ...
}

public class NewStatus: MyStatus
{
    public override void Start(MyProgress progress)
    {
        progress.SetStatus(InProgress);
    }
    public override void Cancel(MyProgress progress)
    {
        progress.SetStatus(Cancelled);
    }
    public override void Fail(MyProgress progress)
    {
            progress.SetStatus(Failed);
    }
}
...

Here is the problem… My enumeration was persisted as an integer field on the record. Now that I had a state pattern, how should I save my state? I googled the problem and found Derick Bailey’s article on the state pattern and Fluent NHibernate. Derick’s pattern works well, but I felt that creating a lookup table in my database just so I can persist a value in another table was not the path I wanted to traverse – I wasn’t persisting an entity, I was persisting a state value on an entity. Not finding any more love from Google, I asked around and was advised to contact fellow Elegant Coder and Guild3 member, Jason Grundy. Here is Jason’s advice:

“I’ve recently changed from using Enums to an approach outlined by Jimmy Bogard here.  In the Entity I would do something like this:

protected int _orderStatusId;
public virtual OrderStatus OrderStatus
{
    get { return Enumeration.FromValue<OrderStatus>(_orderStatusId); }
    set { _orderStatusId = value.Value; }
}

Then in Fluent NH you can simply map to the protected member.”

I decided to pursue Jason’s advice.  The result is my database tables did not need to change at all. Here is some snippets of the updated classes:

public class MyProgress
{
     public virtual Guid Id {get;set;}
     ...
     protected int _status;
     public virtual MyStatus
     {
         get{ return Enumeration.FromValue<MyStatus>(_status); }
         set{ _status = value.Value; }
     }
     ...
}

public class MyStatus : Enumeration
{
     public static MyStatus New = new NewStatus();
     ...

     private class NewStatus : MyStatus
    {
         public NewStatus() : base (0,"New"){}

         public override void Start(MyProgress progress)
         {
             progress.SetStatus(InProgress);
         }
    }
     ...

Notice that the MyStatus class is no longer abstract.  However, the subclasses are all private nested classes, each with a value and a display name.  I set each subclass value to match the enumeration value it replaced.  I did not need to convert my existing data to a new schema.

And here is the Fluent NHibernate override:

public class MyProgressOverride : IAutoMappingOverride<MyProgress>
{
    public void Override(AutoMapping<MyProgress> mapping)
    {
        mapping.Map(x => x.Status)
            .CustomType(typeof(int))
            .Access.CamelCaseField(Prefix.Underscore);
    }
}

As you can see, we use convention-based automapping with overrides, but this same map could be used in a standard class map.

Thanks to Jimmy, Derick, and Jason for the inspiration and assistance!

At my company, we have embraced convention-over-configuration throughout our applications, from our data access framework (Fluent NHibernate) to our IoC container (StructureMap) to our build scripts to our…well, you get the picture.  However, we had been hitting a pain point in our application when trying to serialize our domain objects for transport across the WCF service layer.  We were also seeing some issues with using domain objects directly in our MVC views. The old way would have been to write that boring left-hand/right-hand code.  We all know that left-hand/right-hand code is ugly and pollutes the methods that should be doing real work with ceremonious busy work. 

Well, just as we were really getting stung by these pain points, Cory and I started talking about AutoMapper.  Now, for those who have no idea what AutoMapper is, check out the Getting Started page on CodePlex.  If you want to check out the source, go to the Google code site.  Jimmy Bogard, the AutoMapper author, describes the AutoMapper as a convention-based object-to-object mapper.

Different Means to an End

Here is the basic idea… In the past, I would write this classic chunk of code:

var meeting = _repository.GetMeetingById(meetingId);
var dto = new MeetingDto();
dto.Begins = meeting.Begins;
dto.End = meeting.End;
dto.Attendees = meeting.Attendees;
dto.AttendeesCount = meeting.Attendees.Count;
//do something meaningful

With AutoMapper, I can write this instead:

var meeting = _repository.GetMeetingById(meetingId);
var dto = Mapper.Map<Meeting, MeetingDto>(meeting);
//do something meaningful

Herein lies the beauty of AutoMapper.  When your classes align themselves conventionally, your mapping configuration can be as simple as:

CreateMap<Meeting,MeetingDto>();

This is a trivial example, but where AutoMapper shines is in the ability to map lists and nested properties by convention. Or constructing an object based on another object’s properties.  All without littering a method with ceremonial code.

Using an object-to-object mapper does have its drawbacks:

1. The classic left-hand/right-hand code performs faster than mapped code, although Jimmy has made great strides in increasing performance.
2. When defining unconventional mappings, you will still have left-hand/right-hand code
3. There will be a learning curve for you (and/or your team) if you have not had experience with convention-based frameworks or some of the .NET 3.5 features.

However, we have found these drawbacks to be trivial when compared to the benefits.

Mapping Toolset

In addition to providing the convention mappings, Jimmy has provided a toolset for enhancing the mappings. Listed here are several tools we either use or find compelling.

Custom Converters: Code to convert from source type to destination type. Defined once and implicitly used for all mappings. 

Custom Resolvers: Code to convert from source value to destination value.  Defined once for use by any mapping, but must be explicitly used by a mapping.

Custom Formatters: Code to reformat a type for presentation.  Like resolvers, formatters are defined once and explicitly used.

Before/After Map Functions: Provides the ability to run custom code before or after the mappings are performed.

Validation Assertion: Provides a method to short-circuit at runtime (or in tests) with an explanatory exception when a mapping may cause failures. 

Mapping Profiles: Profile is a base class that helps you organize your code.  If you are familiar with StructureMap’s Registry class, you will feel right at home with the Profile class.

Where We Use AutoMapper

We use AutoMapper to transform our object model to our presentation model.  This happens in two places – in our MVC controllers and at our WCF service layer.

In the controllers, we will map from a domain model or DTO into the view model.  We will also map from our view model into a message object for use by the service or domain.

At the service layer, we flatten our domain model into a DTO or map a message object to run a command against the domain.

Code Samples

I am including the sample code used at the NETDUG meeting.  The first sample shows different ways to setup mappings (inline vs. profiles).  The second sample shows some usages of custom resolvers, formatters, and before-maps.

Download the AutoMapper source.  Jimmy has provided many sample classes and unit tests showing off the usage of different conventions. 

Matt Hinze also posted a sample solution using AutoMapper with NerdDinner (of which I borrowed some custom formatter code – Thanks Matt!).

Download the CodeCampServer source.  It is full of examples and conventions, including using an IoC/DI implementation of the AutoMapper engine.