Category Archives: Programming

Getting started with Linq Expressions

The Expression class is used to represent expression trees and is seen in use within LINQ. If you’ve been creating your own LINQ provider you’ll also have come across Expressions. For example see my post Creating a custom Linq Provider on this subject.

Getting started with the Expression class

Expression objects can be used in various situations…

Let’s start by looking at using Expressions to represent lambda expressions.

Expression<Func<bool>> e = () => a < b;

In the above we declare an Expression which takes a Func which takes no arguments and returns a Boolean. On the right hand side of the assignment operator we can see an equivalent lambda expression, i.e. one which takes no arguments and returns a Boolean.

From this Expression we can then get at the function within the Expression by calling the Compile method thus

Func<bool> f = e.Compile();

We could also create the same lambda expression using the Expression’s methods. For example

ConstantExpression lParam = Expression.Constant(a, typeof(int));
ConstantExpression rParam = Expression.Constant(b, typeof(int));
BinaryExpression lessThan = Expression.LessThan(lParam, rParam);
Expression<Func<bool>> e = Expression.Lambda<Func<bool>>(lessThan);

This probably doesn’t seem very exciting in itself, but if we can create an Expression from a lambda then we can also deconstruct an lambda into an Expression tree. So in the previous lambda example we could look at the left and right side of the a < b expression and find the types and other such things, we could evaluate the parts or simply traverse the expression and create database for it, but that’s a subject beyond this post.

An alternate use

An interesting use of Expressions can be found in many MVVM base classes (or the likes). I therefore take absolutely no credit for the idea.

The scenario is this. We want to create a base class for handling the INotifyPropertyChanged interface, it will look like this

public class PropertyChangedObject : INotifyPropertyChanged
{
   public event PropertyChangedEventHandler PropertyChanged;

   public void OnPropertyChanged(string propertyName)
   {
      if (PropertyChanged != null)
      {
         PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
      }
   }
}

Next let’s write a simple class to use this, such as

public class MyObject : PropertyChangedObject
{
   private string name;

   public string Name
   {
      get { return name; }
      set
      {
         if (name != value)
         {
            name = value;
            OnPropertyChanged("Name");
         }
      }
   }
}

As you can see, within the setter, we need to check whether the value stored in the Name property is different to the new value passed to it and if so, update the backing field and then raise a property changed event passing a string to represent the property name.

An obvious problem with this approach is that “magic strings” can sometimes be incorrect (i.e. spelling mistakes or the likes). So it would be nicer if we could somehow pass the property name in a more typesafe and compile time checking way. It would also be nice to wrap the whole if block in an extension method which we can reuse in all the setters on our object.

Note: before we go much further with this, in .NET 4.5 there’s a better way to implement this code. See my post on the CallerMemberNameAttribute attribute.

So one way we could pass the property name, which at least ensure the property exists at compile time, is to use an Expression object which will then include all the information we need (and more).

Here’s what we want the setter code to look like

public string Name
{
   get { return name; }
   set { this.RaiseIfPropertyChanged(p => p.Name, ref name, value); }
}

The second and third arguments are self-explanatory, but for the sake of completeness let’s review them – the second argument takes a reference to the backing field. this will be set to the value contained within the third field only if the two differ. At which point we expect an OnPropertyChanged call to be made and the PropertyChanged event to occur.

The first argument is the bit relevant to the topic of this post, i.e. the Expression class.

Let’s look at the extension method that implements this and then walk through it

public static void RaiseIfPropertyChanged<TModel, TValue>(this TModel po, 
         Expression<Func<TModel, TValue>> e,  
         ref TValue backingField, 
         TValue value) where 
            TModel : PropertyChangedObject
{
   if (!EqualityComparer<TValue>.Default.Equals(backingField, value))
   {
      var m = e.Body as MemberExpression;
      if(m != null)
      {
         backingField = value;
         po.OnPropertyChanged(m.Member.Name);
      }
   }
}

The method can be used on any type which inherits from PropertyChangedObject, this is obviously so we get the method call OnPropertyChanged.

We check the equality of the backingField and value and obviously, only if they’re different do we bother doing anything. Assuming the values are different we then get the Body of the expression as a MemberExpression, on this the Member.Name property will be a string representing the name of the property supplied in the calling property, i.e. in this example the property name “Name”.

So now when we use the RaiseIfPropertyChanged extension method we have a little more type safety, i.e. the property passed to the expression must be the same type as the backing field and value and ofcourse a mis-spelled/none existent property will fail to compile as well, so lessens the chances of “magic string” typos. Obviously if we passed another property of the same type into the Expression then this will compile and seemingly work but the OnPropertyChanged event would be passed an incorrect property string and this is where the CallerMemberNameAttribute would help us further.

Step by step mocking with RhinoMock

Requirements

We’re going to work through a simple set of scenarios/tests using RhinoMocks and NUnit. So we’ll need the following to get started

I’m using the RhinoMocks NuGet package, version 3.6.1 for these samples and the NuGet package for NUnit 2.6.3.

What are we going to mock

For the sake of these examples we’re going to have an interface, which we will mock out, named ISession. Here’s the code for ISession

public interface ISession
{
   /// <summary>
   /// Subscribe to session events
   /// </summary>
   /// <param name="o">the object that recieves event notification</param>
   /// <returns>a token representing the subscription object</returns>
   object Subscribe(object o);
   /// <summary>
   /// Unsubscribe from session events
   /// </summary>
   /// <param name="token">a token supplied via the Subscribe method</param>
   void Unsubscribe(object token);
   /// <summary>
   /// Executes a command against the session object
   /// </summary>
   /// <param name="command">the command to be executed</param>
   /// <returns>an object representing any return value for the given command</returns>
   object Execute(string command);
}

Getting started

Before we can create any mock objects we need to create an instance of the factory class or more specifically the MockRepository. A common pattern within NUnit test fixtures is to create this during the SetUp, for example

[TestFixture]
public class DemoTests
{
   private MockRepository repository;

   [SetUp]
   public void SetUp()
   {
      repository = new MockRepository();
   }
}

The MockRepository is used to create mock objects but also can be used to record, replay and verify mock objects (and more). We’ll take a look at some of these methods as we go through this step by step guide.

If, as is often the cases with tests I’ve written with RhinoMock, we want to verify all expectations on our mocks. Using NUnit we can handle this in the TearDown, for example adding the following to the DemoTests class

[TearDown]
public void TearDown()
{
   repository.VerifyAll();
}

this will verify that all mock expectations have been met when the test fixture is torn down.

Mocks vs DynamicMocks

In previous posts on Moq and JustMock Lite I’ve mentioned strict and loose behavior. Basically loose behavior on a mock object means I do not need to supply expectations for every method call, property invocation etc. on a mocked object, whereas strict means the opposite, in that if we do not supply the expectation an ExpectationViolationExpectation will be thrown by RhinoMocks.

In RhinoMock terminology, mocks have strict semantics whereas dynamic mocks have loose.

So, to see this in action let’s add two tests to our test fixture

[Test]
public void TestMock()
{
   ISession session = repository.CreateMock<ISession>();
   repository.ReplayAll();

   Mapper mapper = new Mapper(session);
}

[Test]
public void TestDynamic()
{
   ISession session = repository.DynamicMock<ISession>();
   repository.ReplayAll();

   Mapper mapper = new Mapper(session);
}

Our Mapper class looks like the following

public class Mapper
{
   private readonly ISession session;
   private object token;

   public Mapper(ISession session)
   {
      this.session = session;

      token = session.Subscribe(this);
   }
}

don’t worry about repository.ReplayAll(), we’ll get to that in a minute or two.

Now if we run these two tests TestDynamic will succeed whereas TestMock will fail with an ExpectationViolationException. The dynamic mock worked because of the loose semantics which means it does not require all expectations set before usage. We can fix the TestMock method by writing an expectation for the call to the Subscribe method on the ISession interface.

So changing the test to look like the following

[Test]
public void TestMock()
{
   ISession session = repository.CreateMock<ISession>();
   Expect.Call(session.Subscribe(null)).IgnoreArguments().Return(null).Repeat.Any();

   repository.ReplayAll();

   Mapper mapper = new Mapper(session);
}

So in the above code we arrange our expectations. Basically we’re saying expect a call on the Subscribe method of the session mock object. In this case we pass in null and tell the mock to ignore the arguments, removing IgnoreArguments means we expect that Mapper will call the Subscribe method passing the exact arguments supplied in the expectation, i.e. in this case null.

Next we’re setting the expectation to return null and we don’t care how many times this method is called, so we call Repeat.Any(). If we wish to change the expectation to ensure the method is called just the once, we can change this to Repeat.Once() which is obviously more specific and useful for catching scenarios where a method is accidentally called more times than necessary. In our Mapper’s case this cannot happen and the method can only be called once, so we’d normally set this to Repeat.Once().

What we’ve done is supply defaults which is what the dynamic mock object would have probably implemented for our expectations as well. Hence why I used Repeat.Any() to begin with, so the implementation above will now cause the test to succeed.

Record/Playback

Now to return to repository.ReplayAll(). RhinoMocks works in a record/playback way, that is by default it’s in record mode so if in TestDynamic we comment out repository.ReplayAll() we’ll get the exception InvalidOperationException. The mock object is in a record state. We arrange our expectation in the record phase then act upon them during playback. As we are, by default, in record mode we can simply start creating our expectations, then when we’re ready to act on those mocked objects we switch the MockRepository to playback mode using repository.ReplayAll().

Arrange

As already mentioned we need to setup expectations on our mock object (unless we’re using dynamic mocks ofcourse). We do this during the arrange phase as was shown with the line

Expect.Call(session.Subscribe(null)).IgnoreArguments().Return(null).Repeat.Any();

One gotcha is if your method takes no arguments and returns void. So let’s assume ISession now has a method DoSomething which takes no arguments and returns void and see what happens…

Trying to write the following

Expect.Call(session.DoSomething()).Repeat.Any();

will fail to compile as we cannot convert from void to Rhino.Mocks.Expect.Action, we can easily fix by removing the () and using the following line

Expect.Call(session.DoSomething).Repeat.Any();

Equally if the ISession had a property named Result which was of type string we can declare the expectation as follows

Expect.Call(session.Result).Return("hello").Repeat.Any();

We can also setup an expectation on a method call using the following

session.Subscribe(null);
LastCall.IgnoreArguments().Return(null).Repeat.Any();

in this case the LastCall allows us to set our expectations on the previous method call, i.e. this is equivalent to our previous declaration for the expectation on the Subscribe method. This syntax is often used when dealing with event handlers.

Mocking Event Handlers

Let’s assume we have the following on the ISession

event EventHandler StatusChanged;

the idea being a session object may change, maybe to a disconnect state, and we want to have the Mapper respond to this in some way. Then we want to cause events to fire and then see whether the Mapper changes accordingly.

Okay, so let’s rewrite the Mapper constructor to look like the following

public Mapper(ISession session)
{
   Status = "Connected";
   this.session = session;

   session.StatusChanged += (sender, e) =>
   {
      Status = "Disconnected";
   };
}

The assumption is that we have a string property Status and that if a status change event is received the status should switch from Connected to Disconnected.

Firstly we need to handle the expectation of the += being called on the event in ISession, so our test would look like this

[Test]
public void TestMock()
{
   ISession session = repository.CreateMock<ISession>();

   session.StatusChanged += null;
   LastCall.IgnoreArguments();

   repository.ReplayAll();

   Mapper mapper = new Mapper(session);
   Assert.AreEqual("Connected", mapper.Status);
}

Notice we use LastCall to create an expectation on the += being called on the StatusChanged event. This should run without any errors.

Now we want to change things to see if the Mapper Status changes when a StatusChanged event takes place. So we need a way to raise the StatusChanged event. RhinoMocks includes the IEventRaiser interface for this, so rewriting our test as follows, will solve this requirement

[Test]
public void TestMock()
{
   ISession session = repository.CreateMock<ISession>();

   session.StatusChanged += null;
   LastCall.IgnoreArguments();

   IEventRaiser raiser = LastCall.GetEventRaiser();

   repository.ReplayAll();

   Mapper mapper = new Mapper(session);
   Assert.AreEqual("Connected", mapper.Status);

   raiser.Raise(null, null);

   Assert.AreEqual("Disconnected", mapper.Status);
}

Notice we use the LastCall.GetEventRaiser() to get an IEventRaiser. This will allow us to raise events on the StatusChanged event. We could simply combine the LastCall’s to form

IEventRaiser raiser = LastCall.IgnoreArguments().GetEventRaiser();

The call raiser.Raise(null, null) is used to actually raise the event from our test, the two arguments match the arguments on an EventHandler, i.e. an object (for the sender) and EventArgs.

More types of mocks

Along with CreateMock and DynamicMock you may notice some other mock creation methods.

What are the *MultiMocks?

CreateMultiMock and DynamicMultiMock allow us to create a mock (strict semantics for CreateMultiMock and loose for DynamicMultiMock) but supporting multiple types. In other words let’s assume our implementation of ISession is expected to support another interface, IStatusUpdate and this will have the event we’re previously declare, i.e.

public interface IStatusUpdate
{
   event EventHandler StatusChanged;
}

Now we change the Mapper constructor to allow it to check if the ISession also supports IStatusUpdate and only then subscribe to it’s event, for example

public Mapper(ISession session)
{
   Status = "Connected";
   this.session = session;

   IStatusUpdate status = session as IStatusUpdate;
   if (status != null)
   {
      status.StatusChanged += (sender, e) =>
      {
         Status = "Disconnected";
      };
   }
}

and finally let’s change the test to look like

[Test]
public void TestMock()
{
   ISession session = repository.CreateMultiMock<ISession>(typeof(IStatusUpdate));

   ((IStatusUpdate)session).StatusChanged += null;

   IEventRaiser raiser = LastCall.IgnoreArguments().GetEventRaiser();

   repository.ReplayAll();

   Mapper mapper = new Mapper(session);
   Assert.AreEqual("Connected", mapper.Status);

   raiser.Raise(null, null);

   Assert.AreEqual("Disconnected", mapper.Status);
}

As you can see, we’ve now created an mock ISession object which also supports IStatusUpdate.

PartialMock

The partial mock allows us to mock part of a class. For example, let’s do away with our Mapper and just write a test to check what’s returned from this new Session class

public class Session
{
   public virtual string Connect()
   {
      return "none";
   }
}

and our test looks like this

[Test]
public void TestMock()
{
   Session session = repository.PartialMock<Session>();

   repository.ReplayAll();

   Assert.AreEqual("none", session.Connect());
}

This will run and succeed when we use the PartialMock as it automatically uses the Session objects Connect method, but we can override this by using the following

[Test]
public void TestMock()
{
   Session session = repository.PartialMock<Session>();

   Expect.Call(session.Connect()).Return("hello").Repeat.Once();

   repository.ReplayAll();

   Assert.AreEqual("hello", session.Connect());
}

Now if instead we use CreateMock in the above this will still work, but if we remove the Expect.Call the mock does not fall back to using the Session Connect method but instead fails with an exception, ExpectationViolationException.

So if you need to mock a concrete object but have the code use the concrete class methods in places, you can use the PartialMock.

Note: You methods on the Session class need to be marked as virtual for the above to work

Obviously a PartialMultiMock can be used to implement more than one type.

Stubs

A stub is generally seen as an implementation of a class with minimal functionality, i.e. if we were to implement any of our ISession interfaces (shown in this post) and for properties we simply set and get from a backing store, methods return defaults and do nothing. Methods could return values but it’s all about minimal implementations and consistency. Unlike mocks we’re not trying to test behavior, so we’re not interested in whether a method was called once or a hundred times.

Often a mock with loose semantics will suffice but RhinoMock includes a specific type that’s created via

repository.Stub<ISession>();

the big difference between this and a dynamic mock is that in essense properties are all declared as

Expect.Call(session.Name).PropertyBehavior();

implicitly (PropertyBehavior is discussed in the next section). This means if we run a test using a dynamic mock, such as

ISession session = repository.DynamicMock<ISession>();
repository.ReplayAll();

session.Name = "Hello";

Assert.AreEqual(null, session.Name);

The property session.Name will be null even though we assigned it “Hello”. Using a stub, RhinoMocks gives us an implementation of the property setter/getter and thus the following would result in a test passing

ISession session = repository.DynamicMock<ISession>();
repository.ReplayAll();

session.Name = "Hello";

Assert.AreEqual("Hello", session.Name);

i.e. session.Name now has the value “Hello”.

Mocking properties

So, we’ve got the following interface

public interface ISession
{
   string Name { get; set; }
}

now what if we want to handle the getter and setter as if they were just simple setters and getters (i.e. implemented exactly as shown in the interface). Instead of creating return values etc. we can use a short cut

Expect.Call(session.Name).PropertyBehavior();

which basically creates an implementation of the property which we can now set and get from without setting full expectations, i.e. the following test shows us changing the Name property after the replay

[Test]
public void TestMock()
{
   ISession session = repository.CreateMock<ISession>();

   Expect.Call(session.Name).PropertyBehavior();

   repository.ReplayAll();

   session.Name = "Hello";
   Assert.AreEqual("Hello", session.Name);
}

Generating classes from XML using xsd.exe

The XML Schema Definition Tool (xsd.exe) can be used to generate xml schema files from XML and better still C# classes from xml schema files.

Creating classes based upon an XML schema file

So in it’s simplest usage we can simply type

xsd person.xsd /classes

and this generates C# classes representing the xml schema. The default output is C# but using the /language or the shorter form /l switch we can generate Visual Basic using the VB value, JScript using JS or CS if we wanted to explicitly static the language was to be C#. So for example using the previous command line but now to generate VB code we can write

xsd person.xsd /classes /l:VB

Assuming we have an xml schema, person.xsd, which looks like this

<?xml version="1.0" encoding="utf-8"?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Person" nillable="true" type="Person" />
  <xs:complexType name="Person">
    <xs:sequence>
      <xs:element minOccurs="0" maxOccurs="1" name="FirstName" type="xs:string" />
      <xs:element minOccurs="0" maxOccurs="1" name="LastName" type="xs:string" />
      <xs:element minOccurs="1" maxOccurs="1" name="Age" type="xs:int" />
    </xs:sequence>
  </xs:complexType>
</xs:schema>

The class created (in C#) looks like the following (comments removed)

[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "4.0.30319.17929")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="", IsNullable=true)]
public partial class Person {
    
    private string firstNameField;
    
    private string lastNameField;
    
    private int ageField;
    
    public string FirstName {
        get {
            return this.firstNameField;
        }
        set {
            this.firstNameField = value;
        }
    }
    
    public string LastName {
        get {
            return this.lastNameField;
        }
        set {
            this.lastNameField = value;
        }
    }
    
    public int Age {
        get {
            return this.ageField;
        }
        set {
            this.ageField = value;
        }
    }
}

Creating an XML schema based on an XML file

It might be that we’ve got an XML file but no xml schema, so we’ll need to convert that to an xml schema before we can generate our classes file. Again we can use xsd.exe

xsd person.xml

the above will create an xml schema based upon the XML file, obviously this is limited to what is available in the XML file itself, so if your XML doesn’t have “optional” elements/attributes xsd.exe obviously cannot include those in the schema it produces.

Assuming we therefore started with an XML file, the person.xml, which looks like the following

<?xml version="1.0" encoding="utf-8"?>

<Person>
   <FirstName>Spoungebob</FirstName>
   <LastName>Squarepants</LastName>
   <Age>21</Age>
</Person>

Note: I’ve no idea if that is really SpongeBob’s age.

Running xsd.exe against person.xml file we get the following xsd schema

<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
  <xs:element name="Person">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" minOccurs="0" />
        <xs:element name="LastName" type="xs:string" minOccurs="0" />
        <xs:element name="Age" type="xs:string" minOccurs="0" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="Person" />
      </xs:choice>
    </xs:complexType>
  </xs:element>
</xs:schema>

From this we could now create our classes as previously outlined.

Creating an xml schema based on .NET type

What if we’ve got a class/type and we want to serialize it as XML, let’s use xsd.exe to create the XML schema for us.

If the class looks like the following

public class Person
{
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public int Age { get; set; }
}
[code]

<em>Note: Assuming the class is compiled into an assembly call DomainObjects.dll</em>

Then running xsd.exe with the following command line

[code language="xml"]
xsd.exe DomainObjects.dll /type:Person

will then generate the following xml schema

<?xml version="1.0" encoding="utf-8"?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Person" nillable="true" type="Person" />
  <xs:complexType name="Person">
    <xs:sequence>
      <xs:element minOccurs="0" maxOccurs="1" name="FirstName" type="xs:string" />
      <xs:element minOccurs="0" maxOccurs="1" name="LastName" type="xs:string" />
      <xs:element minOccurs="1" maxOccurs="1" name="Age" type="xs:int" />
    </xs:sequence>
  </xs:complexType>
</xs:schema>

You’ll notice this is slightly different from the code generated from the person.xml file.

Messing around with JustMock lite

I’ve been trying out JustMock Lite (hereon known as JML), from Telerik – the lite version is free and source available on Github. The package is installable via NuGet.

So let’s start with a simple Arrange-Act-Assert sample

IFeed feed = Mock.Create<IFeed>();

// arrange
Mock.Arrange(() => feed.Update(10)).Returns(true).OccursOnce();

// act
feed.Update(10);

// assert
Mock.Assert(feed);

The example above shows how we create a mock object based upon the IFeed interface. We then arrange the mocked methods etc. The next step in the sample above is where we use the mocked methods before finally setting assertions.

Note: We do not get a “mock” type back from Mock.Create as we would with a framework like Moq, but instead we get the IFeed which I rather like, not having to use the mock’s Object property to get the type being mocked. This is because in Moq the setup/arrange phase and for that matter the assert phase are all instance methods on the mock object, in JML we use static methods on the Mock class

Loose vs Strict

By default JML creates mocks with Behavior.Loose which means that we don’t need to supply all calls on the mock object upfront via the arrange mechanism. In other words, using Behavior.Loose simply means we might make calls on a mocked object’s methods (for example) without having to explicitly setup the Arrange calls and we’ll get default beaviour. Behavior.Strict means any calls we make on the mock object must have been set-up prior to being called on the mocked object.

Let’s look at an example of using JML’s strict behaviour

public interface IReader
{
   IEnumerable<string> ReadLine();
   string ReadToEnd();
}

[Fact]
public void ReadLine_EnsureCsvReaderUsesUnderlyingReader()
{
   IReader reader = Mock.Create<IReader>(Behavior.Strict);

   Mock.Arrange(() => reader.ReadLine()).Returns((IEnumerable<string>)null);

   CsvReader csv = new CsvReader(reader);
   csv.ReadLine();

   Mock.Assert(reader);
}

In the above, assuming (for the moment) that csv.ReadLine() calls the IReader ReadLine method, then all will be work. But if we remove the Mock.Arrange call we’ll get a StrictMockException as we’d expect as we’ve not setup the Arrange calls. Switching to Behavior.Loose in essence gives us a default implementation of the IReader ReadLine (as we’ve not explicitly provided one via the Mock.Arrange method) and all will work again.

As per other mocking frameworks this simply means if we want to enforce a strict requirement for each call on our mocked object to first be arranged, then we must do this explicitly.

JML also has two other behaviors, Behavior.RecursiveLoose which allows us to create loose mocking on all levels of the mocked object.

The Behavior.CallOriginal sets the mock object up to, by default, call the actual mocked object’s methods/properties. Obviously this means it cannot be used on an interface or abstract method, but what it does mean is that we can mock a class’s virtual method/property (JustMock elevated – the commercial version of JustMock – looks like it supports non virtual/abstract mocking on classes) and by default call the original object’s methods and only Arrange those methods/properties we want to alter.

For example, the following code will pass our test as JML will call our original code and does not require we Arrange the return on the property Name

public class Reader
{
   public virtual string Name { get { return "DefaultReader"; }}
}

[Fact]
public void Name_ShouldBeAsPerTheImplementation()
{
   Reader reader = Mock.Create<Reader>(Behavior.CallOriginal);

   Assert.Equal("DefaultReader", reader.Name);

   Mock.Assert(reader);
}

In some mocking frameworks, such as Moq, will intercept the Name property call and return the default (null) value instead (assuming we’ve not setup any returns ofcourse).

More on CallOriginal

Behavior.CallOriginal sets up the mocked object as, by default, calling the original implementation code, but we can also setup Arrange calls to call the original implementation more explicitly.

For example

public class Reader
{
   public virtual string GetValue(string key)
   {
      return "default";
   }
}

Reader reader = Mock.Create<Reader>();

Mock.Arrange(() => reader.GetValue(null)).Returns("NullReader");
Mock.Arrange(() => reader.GetValue("key")).CallOriginal();

Assert.Equal("NullReader", reader.GetValue(null));
Assert.Equal("default", reader.GetValue("key"));

Mock.Assert(reader);

So here when reader.GetValue is called with the argument “key” the original (concrete implementation) or the GetValue method is called.

Note: Moq also implements such a capability using the CallBase() method

Console.ReadKey and Console.WriteLine deadlock

So, let’s assume we have the following code

static void Main(string[] args)
{
   var interval = Observable.Interval(TimeSpan.FromSeconds(1));

   interval.Subscribe(v => Console.WriteLine("*"));

   Console.ReadKey();
}

There’s nothing too exciting here, We’re using Reactive Extensions to periodically (every second) produce a message which we subscribe to and where we output an asterix to the console when the message arrives at the subscriber. The message is produced on it’s own thread, so we have the main thread running the Main method and the second thread should be outputting an asterix every second.

However if you run this you may well find that there’s no asterixes written to the console.

So what’s the deal ?

Whilst searching around for an answer I came across the reply to the StackOverflow question Strange behaviour of Console.ReadKey() with multithreading. Although my code is very different to that shown by the person asking the question, the reason for the failure to output an asterix to the console is the same.

Basically there’s a race condition which then causes a deadlock.

To verify this I hooked up Visual Studio to the .NET source using the information contained at Configure Visual Studio 2013 for debugging .NET framework, ran the code and then took a look at the code to verify the previously mentioned StackOverlow post…

What happens is that in a situation when the Console.ReadKey is called before Console.WriteLine is…

Console.ReadKey takes a lock on the Console InternalSyncObject and basically loops until it gets input
Next Console.WriteLine runs in it’s own thread and Console.WriteLine calls the Console.Out property which in turn calls Console.InitializeStdOutError (private static method) if Console.Out hasn’t yet been created/initialized
Console.InitializeStdOutError then attempts to obtain a lock on InternalSyncObject which, as we know has already been taken by Console.ReadKey, causing a deadlock until the user presses a key

To get around this we just need to stop Console.ReadKey being hit before Console.Out is initialized, which means we could call Console.WriteLine, Console.Write or Console.Out prior to Console.ReadKey and everything will work correctly as the Console.Out will have been created (and thus InternalSyncObject locked and released) prior to Console.ReadKey going into it’s loop.

So with the following code everything should work fine

static void Main(string[] args)
{
   var interval = Observable.Interval(TimeSpan.FromSeconds(1));

   Console.Write(String.Empty); // write nothing, but causes Console.Out to be initialized

   interval.Subscribe(v => Console.WriteLine("*"));

   Console.ReadKey();
}

Pulse and Wait

The Monitor class contains the static methods Pulse and Wait. Well it has more than those two ofcourse, but these are the two this post is interested in.

Both methods must be enclosed in a lock or more explicitly the object that we pass to Pulse and Wait must have had a lock acquired against it. For example

private readonly object sync = new object();

// thread A
lock(sync)
{
   Monitor.Wait(sync);
}

// thread B
lock(sync)
{
   Monitor.Pulse(sync);
}

In the above code, we have two threads. Thread A acquires a lock on sync and then enters a Wait, at which point the lock is released but the thread now blocks until it reacquires the lock. Meanwhile, thread B acquires the lock on the sync object. It calls Monitor.Pulse which basically moved the waiting thread (thread A) to the ready queue and when thread B releases the lock (i.e. exits the lock block) then the next ready thread (in this case thread A) reacquires the lock and any code after the Monitor.Wait would be executed until it exits the lock block and releases the lock.

Producer-consumer pattern

Okay, I’ll admit to a lack of imagination – the producer consumer pattern also known as the producer consumer queue, is a standard sample for showing Pulse and Wait in use and the excellent Threading C# posts by Joseph Albahari are probably the best place to look for all C# threading information, but we’re going to walk through the producer consumer queue here anyway.

So the producer consumer queue is simply put, a queue whereby multiple threads may add to the queue and as data is added a thread within the queue does something with the data, see Producer–consumer problem.

This example creates one or more threads (as specified in the threadCount) which will be used to process of items from the queue.

The Enqueue method locks then adds the action to the queue and then pulses. The “processing” threads wait for the lock on the sync object being released and makes sure there are still items in the queue (otherwise the threads goes into a wait again). Assuming there is an item in the queue we get the item within the lock to ensure no other thread will have removed it then we release the lock and invoke the action before checking for more items to be processed.

public class ProducerConsumerQueue
{
   private readonly Task[] tasks;
   private readonly object sync = new object();
   private readonly Queue<Action> queue;

   public ProducerConsumerQueue(int threadCount, CancellationToken cancellationToken)
   {
      Contract.Requires(threadCount > 0);

      queue = new Queue<Action>();
      cancellationToken.Register(() => Close(false));

      tasks = new Task[threadCount];
      for (int i = 0; i < threadCount; i++)
      {
         tasks[i] = Task.Factory.StartNew(Process, TaskCreationOptions.LongRunning);
      }
   }

   public void Enqueue(Action action)
   {
      lock (sync)
      {
         queue.Enqueue(action);
         Monitor.Pulse(sync);
      }
   }

   public void Close(bool waitOnCompletion = true)
   {
      for (int i = 0; i < tasks.Length; i++)
      {
         Enqueue(null);
      }
      if (waitOnCompletion)
      {
         Task.WaitAll(tasks);
      }
   }

   private void Process()
   {
      while (true)
      {
         Action action;
         lock (sync)
         {
            while(queue.Count == 0)
            {
                Monitor.Wait(sync);
            }
            action = queue.Dequeue();
         }
         if (action == null)
         {
            break;
         }
         action();
      }
   }
}

Here’s a simple sample of code to interact with the ProducerConsumerQueue

CancellationTokenSource cts = new CancellationTokenSource();

ProducerConsumerQueue pc = new ProducerConsumerQueue(1, cts.Token);
pc.Enqueue(() => Console.WriteLine("1"));
pc.Enqueue(() => Console.WriteLine("2"));
pc.Enqueue(() => Console.WriteLine("3"));
pc.Enqueue(() => Console.WriteLine("4"));

// various ways to exit the queue in an orderly manner
cts.Cancel();
//pc.Enqueue(null);
//pc.Close();

So in this code we create a ProducerConsumerQueue with a single thread, actions are added to the queue via Enqueue and as the ProducerConsumerQueue has only a single thread and as all the items were added from a single thread, each item is simply invoked in the order they were added to the queue. However we could have been adding from multiple threads as the ProducerConsumerQueue is thread safe. Had we created the ProducerConsumerQueue with multiple threads then the order of processing may also be different.

Waiting for a specified number of threads using the CountdownEvent Class

In a previous post I discussed the Barrier class. The CountdownEvent class is closely related to the Barrier in that it can be used to block until a set number of signals have been received.

One thing you’ll notice is that the signal on the Barrier is tied to a wait, in other words you
SignalAndWait on a thread, whereas the CountdownEvent has a Signal and a separate Wait method, hence threads could signal they’ve reach a point then continue anyway or call Wait after they call Signal equally a thread could signal multiple times.

The biggest difference with the Barrier class is that the CountdownEvent does not automatically reset once the specified number of signals have been received. So, once the CountdownEvent counter reaches zero any attempt to Signal it will result in an InvalidOperationException.

You can increment the participants (or in this case we say that we’re incrementing the count) at runtime, but only before the counter reaches zero.

Time for some sample code

class Program
{
   static CountdownEvent ev = new CountdownEvent(5);
   static Random random = new Random();

   static void Main()
   {
      Task horse1 = Task.Run(() => 
            GetReadyToRace("Horse1", random.Next(1, 1000)));
      Task horse2 = Task.Run(() => 
            GetReadyToRace("Horse2", random.Next(1, 1000)));
      Task horse3 = Task.Run(() => 
            GetReadyToRace("Horse3", random.Next(1, 1000)));
      Task horse4 = Task.Run(() => 
            GetReadyToRace("Horse4", random.Next(1, 1000)));
      Task horse5 = Task.Run(() => 
            GetReadyToRace("Horse5", random.Next(1, 1000)));

      Task.WaitAll(horse1, horse2, horse3, horse4, horse5);
   }

   static void GetReadyToRace(string horse, int speed)
   {
      Console.WriteLine(horse + " arrives at the race course");
      ev.Signal();

      // wait a random amount of time before the horse reaches the starting gate
      Task.Delay(speed);
      Console.WriteLine(horse + " arrive as the start gate");
      ev.Wait();
  }
}

In the above code, each thread signals when it “arrives at the race course”, then we have a delay for effect and then we wait for all threads to signal. The CountdownEvent counter is decremented for each signal and threads wait until the final thread signals the CountdownEvent at which time the threads are unblocked and able to complete.

As stated previously unlike the Barrier once all signals have been received there’s no reset of the CountDownEvent, it has simply finished it’s job.

Using ThreadStatic and ThreadLocal

First off these are two different objects altogether, ThreadStatic is actually ThreadStaticAttribute and you mark a static variable with the attribute. Whereas ThreadLocal is a generic class.

So why are we looking at both in the one post?

Both ThreadStatic and ThreadLocal are used to allow us to declare thread specific values/variables.

ThreadStatic

A static variable marked with the ThreadStatic attribute is not shared between threads, therefore each thread gets it’s own instance of the static variable.

Let’s look at some code

[ThreadStatic]
static int value;

static void Main()
{
   Task t1 = Task.Run(() =>
   {
      value++;
      Console.WriteLine("T1: " + value);
   });
   Task t2 = Task.Run(() =>
   {
      value++;
      Console.WriteLine("T2: " + value);
   });
   Task t3 = Task.Run(() =>
   {
      value++;
      Console.WriteLine("T3: " + value);
   });

   Task.WaitAll(t1, t2, t3);
}

The output from this (obviously the ordering may be different) is

T3: 1
T1: 1
T2: 1

One thing to watch out for is that if we initialize the ThreadStatic variable, for example if we write the following

[ThreadStatic]
static int value = 10;

you need to be aware that this is initialized only on the thread it’s declared on, all the threads which use value will get a variable initialised with it’s default value, i.e. 0.

For example, if we change the code very slightly to get

[ThreadStatic]
static int value = 10;

static void Main()
{
   Task t1 = Task.Run(() =>
   {
      value++;
      Console.WriteLine("T1: " + value);
   });
   Task t2 = Task.Run(() =>
   {
      value++;
      Console.WriteLine("T2: " + value);
   });
   Task t3 = Task.Run(() =>
   {
      value++;
      Console.WriteLine("T3: " + value);
   });

   Console.WriteLine("Main thread: " + value);
   
   Task.WaitAll(t1, t2, t3);
}

The output will look something like

Main thread: 10
T2: 1
T1: 1
T3: 1

Finally as, by definition each variable is per thread, operations upon the instance of the variable are thread safe.

ThreadLocal

Like the ThreadStatic attribute, the ThreadLocal class allows us to declare a variable which is not shared between threads, one of the extra capabilities of this class is that we can initialize each instance of the variable as the class the supplied factory method to create and/or initialize the value to be returned. Also, unlike ThreadStatic which only works on static fields, ThreadLocal can be applied to static or instance variables.

Let’s look at the code

static void Main()
{
   ThreadLocal<int> local = new ThreadLocal<int>(() =>
   {
      return 10;
   });

   Task t1 = Task.Run(() =>
   {
      local.Value++;
      Console.WriteLine("T1: " + local.Value);
   });
   Task t2 = Task.Run(() =>
   {
      local.Value++;
      Console.WriteLine("T2: " + local.Value);
   });
   Task t3 = Task.Run(() =>
   {
      local.Value++;
      Console.WriteLine("T3: " + local.Value);
   });

   Task.WaitAll(t1, t2, t3);
   local.Dispose();
}

The output order may be different, but the output will read something like

T2: 11
T3: 11
T1: 11

As you can see, each thread altered their own instance of the thread local variable and more over we were able to set the default value to 10.

The ThreadLocal class implements IDisposable, so we should Dispose of it when we’ve finished with it.

Apart from Dispose all methods and protected members are thread safe.

Waiting for a specified number of threads using the Barrier Class

First off, if you are looking for the definitive online resource on threading in C#, don’t waste your time here. Go to Threading in C# by Joseph Albahari. This is without doubt the best resource anywhere on C# threading, in my opinion (for what it’s worth).

This said, I’m still going to create this post for my own reference

The Barrier Class

The Barrier class is a synchronization class which allows us to block until a set number of threads have signaled the Barrier. Each thread will signal and wait and thus be blocked by the barrier until the set number of signals has been reach at which time they will all be being unblocked, allowing them to continue. Unlike the CountdownEvent, when the Barrier has been signalled the specified number of times it resets and can block again and again awaiting for specified number of threads to signal.

Where would a synchronization class be without a real world analogy – so, let’s assume we are waiting for a known number of race horses (our threads) to arrive at a start barrier (our Barrier class) and once they all arrive we can release them. Only when they’ve all reached the end line (the Barrier class again) do we output the result of the race.

Let’s look at some code (note: this sample can just be dropped straight into a console app’s Program class)

static Barrier barrier = new Barrier(5, b => 
         Console.WriteLine("--- All horse have reached the barrier ---"));
static Random random = new Random();

static void Main()
{
   Task horse1 = Task.Run(() => Race("Horse1", random.Next(1, 1000)));
   Task horse2 = Task.Run(() => Race("Horse2", random.Next(1, 1000)));
   Task horse3 = Task.Run(() => Race("Horse3", random.Next(1, 1000)));
   Task horse4 = Task.Run(() => Race("Horse4", random.Next(1, 1000)));
   Task horse5 = Task.Run(() => Race("Horse5", random.Next(1, 1000)));

   // this is solely here to stop the app closing until all threads have completed
   Task.WaitAll(horse1, horse2, horse3, horse4, horse5);
}

static void Race(string horse, int speed)
{
   Console.WriteLine(horse + " is at the start gate");
   barrier.SignalAndWait();

   // wait a random amount of time before the horse reaches the finish line
   Task.Delay(speed);
   Console.WriteLine(horse + " reached finishing line");
   barrier.SignalAndWait();
}

Maybe I’ve taken the horse race analogy a little too far :)

Notice that the Barrier constructor allows us to add an action which is executed after each phase, i.e. when the specified number of threads have signalled the barrier.

We can add participants to the barrier at runtime, so if we were initially waiting for three threads and these created another three threads (for example), we could then notify the barrier that we want to add the three more threads using the AddParticipant or AddParticipants methods. Likewise we could reduce the participant count using RemoveParticipant or RemoveParticipants.

As you can see from the code above, when a thread wishes to signal it’s completed a phase of it’s processing it calls the SignalAndWait method on the barrier. With, as the name suggests, signals the Barrier class then waits until the Barrier releases it.

More Moq

In the previous post we touched on the fundamentals of using Moq, now we’ll delve a little deeper.

Please note, MOQ version 4.20 has introduced a SponsoreLink which appears to send data to some third party. See discussions on GitHub.

Verifications

So we can verify that a method or property has been called using the following

var mock = new Mock<IFeed>();

FeedViewModel vm = new FeedViewModel(mock.Object);
vm.Update();

mock.Verify(f => f.Update());

This assumes that the vm.Update() calls the IFeed.Update().

But what if we are passing a mock into a view model and we want to verify a method on the mock is called but we don’t care about the specific arguments passed into the method. We can do the following (this example uses the IEventAggregator in Caliburn Micro)

var eventMock = new Mock<IEventAggregator>();

PostListViewModel vm = new PostListViewModel(eventMock.Object);

eventMock.Verify(e => e.Subscribe(It.IsAny<PostListViewModel>()), Times.Once);

In the above example, PostListViewModel’s constructor is expected to call the Subscribe method on the IEventAggregator. The actual implementation passes this into the Subscribe method, but we’ll ignore the argument, except that we’re expecting it to be of type PostListViewModel. The It.IsAny() handles this and the Times.Once simply verifies the Subscribe method was called just once.

My Memory

Outsourcing my memory and thoughts (and other ramblings) to the web