using(var transaction = new TransactionScope(TransactionScopeOption.Required))
{
    using(var connection1 = new SQLiteConnection(_connectionString))
    {
        connection1.Open();

        ... // Do stuff with the open connection

    } // Closes the connection (so we think …)

    using(var connection2 = new SQLiteConnection(_connectionString))
    {
        // This line of code throws a SQLiteException with an error 
        // code 'Busy' after a certain timeout has been expired
        connection2.Open();          

        ...
    }
}

Everything works just fine with the first connection, but the second connection forms a bigger problem. Calling the Open method on the second connection throws a SQLiteException with the message “The database file is locked” and an error code ‘Busy’ after a particular timeout has been expired.

At first I didn’t have a clue, largely because the TransactionScope was nicely tucked away at a much higher level (NServiceBus deals with transactions for me). But after reading more about the intrinsic behavior of SQLite it all started to make sense. Apparently SQLite supports only one writer at a time. The TransactionScope holds an exclusive writer lock, even when disposing the first connection. Because the first connection cannot fully close itself, opening the second connection results in a lock error.

Hope this helps explain why the obvious isn’t obvious .

After hearing about this book in an interview with Mary and Tom Poppendieck, I decided to immediately purchase the audio version on Audible and listen to it during my daily commute to and from work. This book is all about how to enable and inspire change in all kinds of environments, be it at work, your local community or your private life.

The authors Chip Heath and Dan Heath make the advice to focus on the so-called “bright spots”. Most people, including myself, focus on flawed behavior and the things that go wrong. Instead, we should first be looking at the the things that go right, copy and do more of it in order to make change happen. Scaling up the “bright spots” instead of focusing on the negative parts.

In the book, change management is compared with an elephant with a rider on his back who are following a certain path.

The topic of change is therefore broken down in three simple sections:

1. Direct the Rider - This represents the rational and logical part of the brain. This thoughtful part responds well to reason, facts and provides long-term thinking. In order to tell the rider what to do, just provide good arguments.
2. Motivate the Elephant - This part of our brain responds to emotions and short-term gain. This is the biggest part and one where the Rider has limited control over, so both need to be convinced.
3. Shape the Path - This completes the analogy made by the authors representing the Path which the Elephant and Rider are following.

When we’re faced in making a decision, we’re often torn between our rational, logical reasons
and our emotional, intuitive feelings. The general consensus in the book is that if the Rider can direct the Elephant down a well prepared Path then there is a good chance for change. The authors filled the book with dozens of real-life, scientific and practical examples where these principles worked brilliantly (there’s even a story about BP and oil-drilling!!).

These are the nine steps that are illustrated by these anecdotal stories:

1. Find the bright spots – Focus on the successes and not the failures.
2. Script the critical moves – Remove decision paralysis by laying down small and easy steps.
3. Point to the destination – Clearly describe and put out a goal that is hard to neglect and to which people can relate.
4. Find the feeling – Try to find an emotional connection.
5. Shrink the change – As agilists we all know the value of taking small steps. All big things are accomplished in tiny small steps. Change is no exception.
6. Grow your people – Stimulate the “growth mindset” in people, helping to create a new identity to which people can relate.
7. Tweak the environment – Make the necessary changes to peoples’ environment in order to point to the right direction.
8. Build habits – Change peoples’’ habits in order to change long-term behavior.
9. Rally the herd – Use the power of group behavior.

The first three steps are targeted at directing the Rider, the next three steps on motivating the Elephant and the last three steps on shaping the Path.

You just need to read this book for yourself and utilize all the information that you’ve picked up from it. Just give it a try. Its a quick read (or listen) and afterwards, you’d be glad you did.

I always considered Java to be some kind of parallel universe compared to .NET where a lot of interesting lessons can be learned. I never did any serious Java development throughout my professional career, but I like to follow up on the trends in the Java community. Although the Java community suffers from some of the same diseases as the .NET community, the wide-spread acceptance of open-source and the adoption of new, fascinating languages on top of the JVM is an interesting evolution that I feel is lacking in the .NET world. Although the CLR/DLR is probably better designed to host a wider diversity of programming languages than the JVM, the rise of programming languages like Scala, Clojure, Groovy and others is more sparse in the Java universe. Some of the most useful open-source projects in .NET today  initially started out by porting the code of established Java libraries, like NUnit, NHibernate and Spring.NET, etc. …. Anyway, we’re wandering off.

Did you ever need to interoperate with a Java library while developing .NET applications? I have to admit, it doesn’t come up very often but when it does (especially when using IBM products ), IKVM.NET might save you from a whole lot of trouble.

With IKVM.NET its possible to use Java API’s from a .NET application or even to use the Java language to develop .NET applications. Let me show you a quick example.

Say for example that you’re done with the DateTime class in .NET and you need a library that gives you more power in dealing with dates and time in your .NET applications. You do a little searching on the web and there it is, a full blown API like Joda Time (I’m well aware that honorable Jon Skeet has ported this framework to .NET already, but bear with me).

All we have to do to start using Joda Time in a .NET application is to download joda-time.jar and feed it to the ikvmc.exe command-line tool that comes with the binaries of IKVM.NET. Out comes a full blown .NET assembly by executing the following command:

ikvmc -target:library joda-time-1.6.jar

There are a whole slew of other options that you can specify here, like signing the resulting assembly (who still does that, really), specifying the assembly version, etc. …

This is how the generated assembly looks like in Reflector.

The following block of code is small utility that I developed to deal with the time zone arithmetic for the Europe Virtual ALT.NET.

using System;
using System.Windows.Forms;
using org.joda.time;
using org.joda.time.format;
using DateTime = org.joda.time.DateTime;
using TimeZone = java.util.TimeZone;

public partial class Main : Form
{
    private const String London = "Europe/London";
    private const String Brussels = "Europe/Brussels";
    private const String EST = "EST";
    private const String MST = "MST";
    private const String PST = "PST";

    public Main()
    {
        InitializeComponent();
        DateTimeTextBox.Text = CurrentDateAndTime();
    }

    private void ConvertButton_Click(Object sender, EventArgs e)
    {
        var dateTime = new DateTime(DateTimeTextBox.Text, DateTimeZone.UTC);

        var london = ConvertToTimeZone(London, dateTime);
        var brussels = ConvertToTimeZone(Brussels, dateTime);
        var est = ConvertToTimeZone(EST, dateTime);
        var mst = ConvertToTimeZone(MST, dateTime);
        var pst = ConvertToTimeZone(PST, dateTime);

        var formatter = BuildDateTimeFormatter();

        ResultTextBox.Text = String.Format(
            "{0} UK, {1} Brussels, {2} EST, {3} MST and {4} PST.",
            london.toString(formatter),
            brussels.toString(formatter),
            est.toString(formatter),
            mst.toString(formatter),
            pst.toString(formatter));
    }

    private static String CurrentDateAndTime()
    {
        return new DateTime(DateTimeZone.UTC).ToString();
    }

    private static DateTime ConvertToTimeZone(String timeZone, DateTime dateTime)
    {
        var targetTimeZone = DateTimeZone
            .forTimeZone(TimeZone.getTimeZone(timeZone));
        return dateTime.toDateTime(targetTimeZone);
    }

    private static DateTimeFormatter BuildDateTimeFormatter()
    {
        return new DateTimeFormatterBuilder()
            .appendHourOfHalfday(2)
            .appendLiteral(":")
            .appendMinuteOfHour(2)
            .appendLiteral(" ")
            .appendHalfdayOfDayText()
            .toFormatter();
    }
}

The distribution of IKVM.NET also comes with .NET implementation of a whole slew of Java class libraries that you can directly use in a .NET application whenever needed.

But remember, as with all things that seem too good to be true, there are a couple of major downsides as well. The one that you run into fairly quickly is generics. I tried generating a .NET assembly from Make It Easy the other day and I noticed that some of the types in the resulting assembly where plain classes while they were defined as generics in the original JAR file. The explanation that I found was that Java checks generics only at compile time and not at runtime. In .NET generics are provided at runtime. If the generics from Java would convert to .NET, then every Java compiler warning would produce a runtime error. All the old code would not run. There is many old code in the Java VM itself.

The IKVM.NET blog is a great resource for some of the other interoperability issues you might experience. Maybe this will come in handy someday, who knows?

Till next time.

Have a look at the following piece of code:

var someString = "Hi there";
if(someVariable)
    someString = "Hello JS Ninja";

The if statement tries to check for the existence of a variable called someVariable which is not declared. Because it’s not declared, the code generated the following reference error:

"someVariable is not defined"

Nonetheless, the following line of code nicely outputs the text “Hi there” which means that the previous code block still executes.

alert(someString);

Suppose we did bother to declare someVariable but that it doesn’t contain a value that evaluates to true. In that case we’d still have the same outcome which is not what we intended. 

A better way to check for the existence of someVariable is to use typeof instead:

var someString = "Hi there";
if("undefined" ==! typeof someVariable)
    someString = "Hello JS Ninja";

This still yields the same output as the previous code sample but now without the reference error. typeof always returns a string no matter what, but the difference now is that we’re testing whether the variable has a value besides undefined.

So the following piece of code outputs “Hello JS Ninja” on the screen:

var someString = "Hi there";
var someVariable = false;

if("undefined" !== typeof someVariable)
    someString = "Hello JS Ninja";

alert(someString);

On the other hand, the following piece of code again results in the message “Hi there”:

var someString = "Hi there";
var someVariable;
if("undefined" !== typeof someVariable)
    someString = "Hello JS Ninja";

alert(someString);

This is the part where I usually get a headache and have to go search for aspirin.

Till next time.

Today I finished reading JavaScript – The Good Parts written by Douglas Crockford. That picture on his website of him speaking with Chuck Norris on the background should make you run to the local bookstore to buy a copy of his book . I instantly knew after listening to one or two podcasts, where the author appeared as a guest, that his book just had to be good. One can easily notice by the way the author speaks and writes about JavaScript that the author definitely knows his stuff on the subject.

This book is a rather quick read because its only 100 pages long (with appendixes ~145 pages). I started reading this book as a complete rookie when it comes to JavaScript. I must say that I can’t recommend this book as a first book on JavaScript. Don’t get me wrong. I really learned a lot from this book without any foreknowledge  whatsoever. But still, I wish the author had written some sort of a “JavaScript for Beginners” book that could precede “The Good Parts” book in order to get up to speed on all the different parts of the language.

This book is so full of little gems on the JavaScript programming language that I don’t know where to begin. The part of chapter 4 on Functions that describe the four patterns of invocation were a real eye opener and the examples on scope with closures really blew my mind. The chapter on regular expressions is also highly recommended. The only chapter that I didn’t like that much is chapter 8 called Methods. This chapter is completely composed with some kind of API documentation of the Array, Number, Object and RegExp and String objects which I found a bit weird in the book. Also make sure to read through the appendixes where the awful and bad parts are written down as well. These explain the particular language features that are best avoided and why they’re not as good as they look.

Nonetheless, I really enjoyed reading this book and learning about the good and also the bad parts of JavaScript. I think I’m going to read one or two beginner books on JavaScript after which I’m going to give it another thorough read.

Until next time

One can use reflection in order to access and use this private class. An even better and more efficient approach would be to use delegates instead. But there’s also another simple and elegant solution which I briefly mentioned in a previous post namely duck typing.

Now in order to access the SqlCommandSet class we need to define an interface with all of the methods we want to access from our code. Reflector can come in handy in this case to determine which particular methods we need.

public interface ISqlCommandSet : IDisposable
{
    SqlConnection Connection { get; set; }

    void Append(SqlCommand command);
    Int32 ExecuteNonQuery();
}

This is pretty much what we need from a SqlCommandSet. Now we can create a factory class for creating instances of the SqlCommandSet class.

public class SqlCommandSetFactory
{
    private readonly Type _typeOfSqlCommandSet;

    public SqlCommandSetFactory()
    {
        var system_data = Assembly.Load("System.Data,
                                         Version=2.0.0.0,
                                         Culture=neutral,
                                         PublicKeyToken=b77a5c561934e089");

        _typeOfSqlCommandSet =
            system_data.GetType("System.Data.SqlClient.SqlCommandSet");
    }

    public ISqlCommandSet CreateSqlCommandSet()
    {
        var instance = Activator.CreateInstance(_typeOfSqlCommandSet, true);
        var dynamicObject = new DynamicObject(instance);
        return dynamicObject.CreateDuck<ISqlCommandSet>();
    }
}

The System.Data assembly is loaded and the type of the SqlCommandSet is determined in the constructor of the factory class. In the factory method itself we first create an instance of the SqlCommandSet class and then use LinFu’s DynamicObject to ‘cast’ it to our ISqlCommandSet interface. And this is pretty much it. Now we can use a SqlCommandSet at will.

using(var connection = new SqlConnection(@"..."))
{
    connection.Open();

    using(var command1 = new SqlCommand("INSERT INTO BLABLA ..."))
    using(var command2 = new SqlCommand("INSERT INTO BLA BLA ..."))
    {
        var commandSet = new SqlCommandSetFactory().CreateSqlCommandSet();
        commandSet.Connection = connection;
        commandSet.Append(command1);
        commandSet.Append(command2);
        commandSet.ExecuteNonQuery();
    }
}

Again I’d like to mention that I’ve been using the DynamicObject class from Linfu 1.0 which you can download here.

Earlier this week I finished reading ASP.NET MVC in Action written by Jeffrey Palermo, Ben Scheirman and Jimmy Bogard.  I came across several good reviews about this book so I finally decided to give a read. 

This book is not just about the API’s of the ASP.NET MVC framework but also about good design principles for creating long-lived web applications. When you’re not familiar with the S.O.L.I.D. principles and also want to learn about the very basics of Domain-Driven Design in the context of web applications, then this book is definitely for you. For me personally, being indoctrinated with this stuff for quite some time now, I didn’t pick up that many new things except for some of the ins and outs of the  ASP.NET MVC framework. 

Nonetheless, I strongly believe that this kind of books are still highly needed to raise the bar of quality in the .NET community. Practices like unit testing, continuous integration, DRY, etc. are sadly enough not part of the mainstream yet. The authors also had the courage to provide an entire chapter where they explore other MVC frameworks like MonoRail and Ruby on Rails which, from my point of view, adds tremendous value to the awareness of the unsuspecting .NET developer.

The first three chapters provide an in dept overview of the parts that constitute the MVC pattern, namely the Model, the View and the Controller. I must say that I’m still not a big fan of the way ASP.NET MVC passes a dictionary of data to its views. I know that you don’t have to use it this way and that a single strongly typed model can be passed to the view. But the presence of a dictionary for me is just a too big a risk that can easily result in creating a mess.

Chapter 5 provides a solid overview of the routing capabilities of the .NET framework including some nice examples. Chapter 6 contains information on how to extend ASP.NET MVC using controller factories, action filters, custom view engines, etc. … . Chapter 7 discusses how to leverage view helpers and creating partial views which I find are quite important features for composing scalable web applications.

Chapter 8 is the one I skimmed through very quickly as it shows how to use existing ASP.NET features with ASP.NET MVC. The part on using existing ASP.NET server controls is totally unnecessary and although you can pull it off in a couple of cases, I advise you to not apply these techniques in a production application.

Chapter 9 shows how to use AJAX in ASP.NET MVC. Pretty basic examples there.

Chapter 10 talks about deployed and contains some interesting ideas on how to use MsBuild, NAnt, Rake, … for automatically deploying a web application into a testing and/or production environment including configuration and environmental setup. 

As already mentioned, chapter 11 shows some basic features of other MVC frameworks. In the last two chapters, the authors provide some best practices and recipes for ASP.NET MVC.

As I already mentioned, if you’re only goal is to get up to speed with the API of ASP.NET MVC then I guess there are better resources out there. For that reason I also bought the Mastering ASP.NET MVC 2.0 series on TekPub to fill in the potential gaps and also to learn more about the new stuff in ASP.NET MVC 2.0.

All in all, I enjoyed reading this book. If I have to give one suggestion for improvement, then I would advocate to add more cohesion to the book. I feel that some topics are scattered all over the place. For example, the use of Castle validators is discussed in two different chapters in the book with some degree of overlap. If only one part of the book was devoted to validation, then its far more easier to go back there for future reference.

I noticed that a second edition of ASP.NET MVC in Action is already available as an early access edition. While looking at the table of contents, some of the content from the first edition has certainly been moved around which I consider to be a good thing. I also hope that the second edition will also include some comparisons with features from Fubu MVC and OpenRasta.

Until next time

I just wanted to put out a slight variation of our solution that defers this kind of type checking until runtime. In other words, we’re going to apply some duck typing in order to come up with some improvements.

But hang on, isn’t C# supposed to be a static language and isn’t duck typing an exclusive feature of dynamic languages like Ruby or Python? Heck no! One can have duck typing in a static language as well. A good example of this is the Boo programming language which is a static language but provides the ability to give up this safety net. But I do believe that dynamic languages like Ruby or Python provide a more supple syntax for supplying duck typing capabilities while a static language usually requires a bit more ceremony.

The latest C# 4.0 compiler delivers some dynamic language features using the dynamic keyword which in turn accomplishes it’s functionality by leveraging the DynamicObject class (which seems to live in the System.Dynamic namespace). I have to admit that I didn’t spent much time on this yet.

But while the rest of the world is still on .NET 3.5 or earlier versions of the .NET framework, we don’t have to wait until the next upgrade to use some of the dynamic language features like duck typing, mixins and the like.

Let me first show you the code of the Account class from the previous post that demonstrates the type checking and casting to a role interface: 

public void Withdraw(double amount)
{
    // One can not always withdraw
    if(false == CanWithdraw())
    {
        // Should throw an exception or at least a towel
        Console.WriteLine("No funds available for withdrawal!");
        return;
    }

    var canWithdraw = (ICanWithdraw)State;
    canWithdraw.Withdraw(amount);

    ...
}

private Boolean CanWithdraw()
{
    return State is ICanWithdraw;
}

What I would like to do is to remove the CanWithdraw check entirely without running into a NullReferenceException when a particular state doesn’t support withdrawing money. But first, I want to slightly decouple the Account class from the SilverState, GoldState and RedState classes by introducing an interface named IAccountStateChanger.

public interface IAccountStateChanger
{
    void InstituteStateTo(State newState);
}

This is now used by the state classes to change the state of the Account class without using a property setter in order to get rid of the false sense of encapsulation. The implementation of this interface by the Account class is where the fun begins.

void IAccountStateChanger.InstituteStateTo(State newState)
{
    _state = newState;
    _dynamicState = new DynamicObject(_state) + _missingStateMethodHandler;
}

Besides having a state we also introduced a dynamic state which is simply an instance of Linfu’s DynamicObject class. I’ll talk about the missing state method handler part shortly, but first let’s look what we can do with our dynamic state object.

public void Withdraw(Double amount)
{
    var canWithdraw = _dynamicState.CreateDuck<ICanWithdraw>();
    canWithdraw.Withdraw(amount);

    ...
}

Notice that we got rid of the type checking part. But what if a particular state doesn’t support withdrawing money? Here’s were the method missing piece of the puzzle falls in. Linfu provides an interface named IMethodMissingCallback which lets you decide what to do when the requested method call cannot be resolved.

public class MissingStateMethodHandler : IMethodMissingCallback
{
    public void MethodMissing(Object source, MethodMissingParameters missingParameters)
    {
        if(typeof(ICanWithdraw).GetMethods()[0].Name == missingParameters.MethodName)
        {
            Console.WriteLine("No funds available for withdrawal!");

            // Let Linfu know we're on top of things        
            missingParameters.Handled = true;
        }
    }

    public Boolean CanHandle(MethodInfo method)
    {
        return false;
    }
}

You can do pretty much anything in here like delegating the call to another method, but for demonstration purposes we just write a message to console. As shown earlier we literally add an instance of this handler to the dynamic object and we’re all set up. Using this approach yields the same results but without the type checking.

I’d like to mention that I’ve been using the DynamicObject class from Linfu 1.0 which you can download here. For some reason this class hasn’t been included in the 2.0 release and higher which is a bit sad because I really like some of the possibilities it has to offer. I’ll cover some of these in one of my next posts.

Just to be clear, I agree and value this approach when it makes sense in the domain model. However, I do not like to entirely give up on the use of the State pattern either. We can eliminate some of the friction by using a very simple approach, namely role interfaces.

To show you a simple example, I took the code of one of the samples on the DoFactory web site and put in some refactoring. Please take a look at the original code before reading any further.

Now instead of having abstract methods on the State base class, I created three separate role interfaces:

public interface ICanDeposit
{
    void Deposit(Double amount);
}

public interface ICanWithdraw
{
    void Withdraw(Double amount);
}

public interface ICanPayInterest
{
    void PayInterest();
}

Both the SilverState and the GoldState class implement all these interfaces, but the one we’re particularly interested in is the RedState class because only deposits should be allowed for this state.

class RedState : State, ICanDeposit
{
    private const Double UpperLimit = 0.0;

    public RedState(State state)
    {
        Balance = state.Balance;
        Account = state.Account;
    }

    public void Deposit(double amount)
    {
        Balance += amount;
        StateChangeCheck();
    }

    private void StateChangeCheck()
    {
        if(Balance > UpperLimit)
            Account.State = new SilverState(this);
    }
}

The RedState therefore only implements the ICanDeposit interface. Just for the record, the code of the State base class is now dramatically reduced.

abstract class State
{
    public Account Account { get; protected set; }
    public Double Balance { get; protected set; }
}

With this setup we can use these role interfaces in the Account class to determine whether a particular operation is allowed for the current state.

public void Withdraw(double amount)
{
    // One can not always withdraw
    if(false == CanWithdraw())
    {
        // Should throw an exception or at least a towel
        Console.WriteLine("No funds available for withdrawal!");
        return;
    }

    var canWithdraw = (ICanWithdraw)State;
    canWithdraw.Withdraw(amount);

    ...
}

private Boolean CanWithdraw()
{
    return State is ICanWithdraw;
}

This way we’re able to eliminate all operations that don’t make sense for a particular state while still being able to determine all of its capabilities when needed.

Hope this helps.

Suppose we have to create some sort of specification that validates the format of an e-mail address. We typically use some regular expression in order to ensure that a specified e-mail address is properly formatted.

public class EmailSpecification
{
    private const String EmailRegexPattern = @".. SOME_REGEX_PATTERN ...";

    public Boolean IsSatisfiedBy(String candidate)
    {
        var regex = new Regex(EmailRegexPattern);
        return regex.IsMatch(candidate);
    }
}

I guess this is pretty common and straightforward. One way to provide some unit tests for this particular piece of code is to check a whole number of e-mail addresses that either pass or fail the specification. The following example shows only a couple of scenarios:

[TestFixture]
public class When_validating_an_email
    : ContextSpecification<EmailSpecification>
{
    protected override EmailSpecification Create_subject_under_test()
    {
        return new EmailSpecification();
    }

    [Test]
    public void ShouldBeSatisfied()
    {
        Assert.That(SUT.IsSatisfiedBy("one2@three.com"));
        Assert.That(SUT.IsSatisfiedBy("one@two3.com"));
    }

    [Test]
    public void ShouldNotBeSatisfied()
    {
        Assert.That(SUT.IsSatisfiedBy("one_two.com"), Is.False);
        Assert.That(SUT.IsSatisfiedBy("one_two@"), Is.False);
    }
}

A slightly more concise approach for these kind of unit tests can be accomplished by utilizing a feature of any decent unit test framework called row tests. With this approach we can, at the very least, reduce the number of asserts we have to write for each unit test. 

[TestFixture]
public class When_validating_an_email__approach_2
    : ContextSpecification<EmailSpecification>
{
    protected override EmailSpecification Create_subject_under_test()
    {
        return new EmailSpecification();
    }

    [RowTest]
    [Row("one2@three.com")]
    [Row("one@two3.com")]
    public void ShouldBeSatisfied(String email)
    {
        Assert.That(SUT.IsSatisfiedBy(email));
    }

    [RowTest]
    [Row("one_two.com")]
    [Row("one_two@")]
    public void ShouldNotBeSatisfied(String email)
    {
        Assert.That(SUT.IsSatisfiedBy(email), Is.False);
    }
}

Notice that I explicitly called both of these approaches unit tests as they don’t have much to do with BDD in my opinion. I’m not saying that using regular unit tests is a bad thing, but with  behavior-driven development context is king. So these unit tests are perfect examples of ‘context betrayal’ when following the BDD approach.

Lets see what MSpec can bring to the table for these kind of scenarios:

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_with_a_number_in_the_local_part
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one2@three.com";

    Behaves_like<SatisfiedSpecificationBehavior> a_satisfied_specification;
}

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_with_a_number_in_the_domain_name
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one@two3.com";

    Behaves_like<SatisfiedSpecificationBehavior> a_satisfied_specification;
}

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_without_an_At_sign
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one_two.com";

    Behaves_like<UnsatisfiedSpecificationBehavior> an_unsatisfied_specification;
}

[Subject(typeof(EmailSpecification), "is satisfied")]
public class when_validating_an_email_address_without_a_domain
    : email_specification_specs
{
    Establish context = () =>
        EmailAddress = "one_two@";

    Behaves_like<UnsatisfiedSpecificationBehavior> an_unsatisfied_specification;
}

In order to escape ‘context betrayal’, we’ve split up every context into a separate context/specification. In order to reduce the amount of effort caused by duplicate code, we stripped the context setup to the bare minimum (just a particular e-mail address in this case). The observations are isolated into MSpec behaviors which provides a very readable description of their outcome. Lets take a look at what is needed in order to get these behaviors to work.

But first lets take at look at the abstract base class that we’ve used for the context/specifications we’ve just shown.

public abstract class email_specification_specs
{
    Establish context = () =>
    {
        SUT = new EmailSpecification();
    };

    Because of = () =>
        Result = SUT.IsSatisfiedBy(EmailAddress);

    protected static Boolean Result;
    protected static String EmailAddress { get; set; }
    protected static EmailSpecification SUT { get; set; }
}

We abstracted as much as possible into this base class in order to remove duplication in the context/specifications. The creation of the subject-under-test and the calling of its IsSatisfiedBy method, but the important one is the declaration of the Result field. This field contains the outcome of the IsSatisfiedBy method. Finally, lets have a look at the behaviors themselves:

[Behaviors]
public class SatisfiedSpecificationBehavior
{
    protected static Boolean Result;

    It should_satisfy_the_specification = () =>
        Result.ShouldBeTrue();
}

[Behaviors]
public class UnsatisfiedSpecificationBehavior
{
    protected static Boolean Result;

    It should_not_satisfy_the_specification = () =>
        Result.ShouldBeFalse();
}

In order to create an MSpec behavior, we just have to create a separate class that we decorate with the Behaviors attribute. Also notice that we have the same declaration of the Result field. MSpec ensures that this field gets initialized with the value of the other Result field that is set in the base class of the context/specifications. Note that you don’t necessarily need to put this field in a base class. You can have that field in every context/specification if you’d like (not sure why) as long as the names match with the fields used in the defined behaviors.

I personally like the way how the MSpec contributors tried to solve testing the same logic with different input patterns and the syntax they provided to back this up.