I’ve been a huge fan of Rhino Mocks since I heard about it on a way-back-episode of Dot Net Rocks HanselMinutes. One of the more awesome features of Rhino Mocks is that it utilizes a Record/Playback semantic so that you can set up your mocks with actual calls to the mock objects, then play them back in your tests. This is great if you rely on intellisense when calling your object instances, or if you use Resharper or another code refactoring tool.

Recently, I trying to use Rhino Mocks with DataTables like so:

DataTable a = new DataTable();
DataTable b = new DataTable(); 

MockObject mock = mockRepository.CreateMock<MockObject>();

using (mockRepository.Record())
{
   Expect.Call(mock.CreateRecord("TableName", a, b).Return(1);
}
using (mockRepository.Playback())
{
  MyObject obj = new MyObject(mock);
  obj.Save();
}

When I ran the test, Rhino Mocks says that a the DataTable created during the obj.Save() call wasn’t the same as the one expected. This was correct as there were now two instances, and it seems that the default check Rhino Mocks performs is an Object.Equals(). Since I needed to do some more deep comparisons of the Expected and Actual DataTables, a fellow developer and I started a very simple DataTableConstraint:

    class DataTableConstraint : AbstractConstraint
    {
        private readonly DataTable _expected;
        private string _errorMessage;

        public DataTableConstraint(DataTable expected)
        {
            _expected = expected;
        }

        public override bool Eval(object obj)
        {
            DataTable actual = obj as DataTable;
            if (actual == null)
                return false;

            if (!CheckColumns(actual))
            {
                return false;
            }
            if (!CheckData(actual))
            {
                return false;
            }
            return true;
        }

        private bool CheckData(DataTable actual)
        {
            if (actual.Rows.Count == 0)
            {
                _errorMessage = "Actual table has no data to compare";
                return false;
            }
            try
            {
                for (int i=0; i < _expected.Rows.Count; i++)
                {
                    foreach (DataColumn column in _expected.Columns)
                    {
                        object expectedCell = _expected.Rows[i][column];
                        object actualCell = actual.Rows[i][column];

                        if (expectedCell != actualCell)
                        {
                            _errorMessage = string.Format("Expected {0} in Row ({1}), Column ({2}), but was {3}", expectedCell, i, column.ColumnName, actualCell);
                            return false;
                        }
                    }
                }
                return true;
            }
            catch (System.Exception e)
            {
                _errorMessage = e.Message;
                return false;
            }
        }

        private bool CheckColumns(DataTable actual)
        {
            foreach (DataColumn column in _expected.Columns)
            {
                if (!actual.Columns.Contains(column.ColumnName))
                {
                    _errorMessage = string.Format("Could not find column {0} in {1}", column, actual);
                    return false;
                }
            }
            return true;
        }

        public override string Message
        {
            get { return _errorMessage; }
        }
    }

To use this using the above sample code, do

Expect.Call(mock.CreateRecord(null, null, null).Constraints
(
  Is.Anything(),
  new DataTableConstraint(a),
  new DataTableConstraint(b)
);

Now, this is just a start, and will probably evolve more as I start to get more into verifying the data in two tables. Perhaps Oren will create a new Syntax Helper along the lines of Data.Equals(expectedDataTable) since using a new Constraint() call is a little awkward.

ANTLR is a DSL tool that can generate a language parser based on a grammar (*.g) file. From there, you hook into the parser so that your code can interpret the language into constructs your application can understand. But, in order to get your grammar file correct, you make end up using a variety of development methods such as TDD, and all of them will have the same step: run the ANTLR tool against your grammar file to generate your parser code.The ANTLR web site has an article on its wiki that will let you integrate the ANTLR tool into your Visual Studio Build process. Follow the steps outlined in that article first.  Since VS 2008 project files are basically MS Build files, the steps work almost verbatim. However, here are a few caveats I encountered:The Exec command in the GenerateAntlrCode target needed some classpath modifications. Basically, I needed to tell java where the Antlr jar file was located. Here is what I ended up with:

1:  <Target Name="GenerateAntlrCode" Inputs="@(Antlr3)" Outputs="%(Antlr3.OutputFiles)">     2:      <Exec Command="java -cp %22$(Antlr3ToolPath)\antlr.jar;$(Antlr3ToolPath)\antlr-3.0.1.jar;$(Antlr3ToolPath)\stringtemplate-3.1b1.jar%22 org.antlr.Tool -message-format vs2005 -lib $(AntlrGrammarPath)  @(Antlr3)" Outputs="%(Antlr3.OutputFiles)" />     3:    </Target>

A couple of notes regarding this target:

• %22 is the escaped form of double-quotes (“)
• I decided to create a build variable so that any changes to a path was updated everywhere (DRY principle).
• You need to reference several jars:
  • antlr.jar -> The Antlr 2.7.7 tool
  • antlr-3.0.1.jar -> The Antlr 3.0.1 tool
  • stringtemplate-3.1b1.jar -> The String Template library

The antlr 2.7.7 jar is needed for the StreamToken class that seems to be in a different namespace than the 3.0.1 jar.The properties called Antlr3ToolPath and Antlr3GrammarPath are defined in a property group like so:

1:    <PropertyGroup>     2:      <Antlr3ToolPath>$(MSBuildProjectDirectory)\..\..\Tools\ANTLR</Antlr3ToolPath>    3:      <AntlrGrammarPath>$(MSBuildProjectDirectory)\Model\Parsers</AntlrGrammarPath>     4:      <BuildDependsOn>GenerateAntlrCode;$(BuildDependsOn)</BuildDependsOn>     5:    </PropertyGroup>

The reason the GrammarPath is basically pointing to the output folder of the parser. This is needed because I am using the ANTLR output option of AST, which generates an Abstract Syntax Tree that much be consumed by another ANTLR grammar. For more details on why you need two grammar files for this process, I recommend the book The Definitive ANTLR Reference, by Terrence Parr.After that, I was able to use Visual Studio to generate the code on every build of the code. When using TDD tools like resharper or testdriven.net, this is an added bonus in that any changes made to the grammar are incorporated in my unit tests. Bonus number 2: since the changes are within the project file itself, and since my continuous integration server is based on my Visual Studio Solution file, the grammar files are also included on my build server and will cause the build to fail if the grammar fails to compile.I hope your build goes just as nicely.