Metup June 2011

The .Net Meetup in June was well attended with a strong Lab49 contingent in attendance.  The topics and speakers were a big draw for me.  All that and pizza too.  I enjoyed it.

FSharpSpec

Thorsten Lorenz gave a high level introduction to BDD and detailed his testing framework FSharpSpec.  The B is for behavior and I’m sure you know about the DD part.

I was quite impressed with Thorsten’s feature rich unit tester.  His comparison of frameworks reminded me that there’s more to testing than coverage. He even has his own mocks.  Pretty clever.

I was looking forward to hearing Snuggs speak about Git.  He’s widely versed in technology and a character to boot.  He did not disappoint.

I’ve heard about Git several times before, but never enough or in the right way to see why I should be using it.  Snuggs told us about about the internals, that its all about the branches and how awesome single feature commits and rollbacks can be.  Don’t forget about GitHub “it’s like facebook for programmers”.

Something definitely clicked and for the next few days I was repeatedly seeing issues I expected Git would help resolve better. I heard that some clients are using Git, so I can definitely see Git in my future.

Freakin’ Moq

While I, like many developers,  appreciate Moq immensely, its not perfect.

Here’s an interesting way to freak out Moq 3.1:

It seems that if you use a 2 dimensional array as a parameter (a common scenario in fixed income) Moq will throw an error when accessing the Moq’d object.

This code:

public interface IFreakOutMoq { void FooBar(string[,] Strings); }

var badMock = new Mock<IFreakOutMoq>();
var badMockObj = badMock.Object;   //exception here

Will throw one of these exceptions (I’ve seen both on different systems):

System.TypeLoadException: System.TypeLoadException: Signature of the body and declaration in a method implementation do not match.

System.TypeLoadException: Method ‘FooBar’ does not have an implementation..

A simple solution is to use a Moq friendly object instead of the 2D array:

public class TwoDArray<T> {
private readonly T[,] _array;

public TwoDArray(T[,] array)     {    _array = array;     }

public T this[int x, int y]     {         get { return _array[x, y]; }     }
public T[,] Array     {         get { return _array; }     }   }
}

Here’s a test class that shows a working and failing example:

using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
using TestProject;   namespace TestProject
{   /// <summary>
/// an array implementation that doesn't 
///     freak Moq out on MockObj.Obj
/// 
/// if you put a 2d array as a param and call mockedObj.Object
/// moq will throw exception: 
///     System.TypeLoadException: System.TypeLoadException: 
///             Signature of the body and declaration 
///             in a method implementation do not match. 
///     or  System.TypeLoadException: Method 'FooBar' 
///             does not have an implementation..
/// 
/// this object can be used instead and moq is fine
/// </summary>
/// <typeparam name="T"></typeparam>
public class TwoDArray<T>
{
private readonly T[,] _array;       public TwoDArray(T[,] array)     {         _array = array;     }
public T this[int x, int y]     {         get { return _array[x, y]; }     }
public T[,] Array     {         get { return _array; }     }
}   }
/// <summary>
/// mocking this interface causes: 
/// System.TypeLoadException: 
///         Method 'FooBar' in type 
///         'IFreakOutMoqProxy2dec23fc008646958fc3bae70cbe067b' 
///         does not have an implementation..
/// </summary>
public interface IFreakOutMoq
{
void FooBar(string[,] Strings);
}     public interface IMoqOK
{
void FooBar(TwoDArray<string> Strings);
}   /// <summary>
/// Summary description for UnitTest1
/// </summary>
[TestClass]
public class UnitTest1
{   [TestMethod]
public void TestMethod1()
{
var goodMock = new Mock<IMoqOK>();
var mockObj = goodMock.Object;
var badMock = new Mock<IFreakOutMoq>();
var badMockObj = badMock.Object;  //exception will be thrown here
Assert.IsNotNull(mockObj);
Assert.IsNotNull(badMockObj);   }
}

Moq Does That

I just needed to Mock multiple interfaces for the first time and it was there and super easy to use.

Thank you Moq.

@Lab This Week 11/27

Just Test – Nuff Said? Nah.

Big discussion about unit testing.  Views ranged from 100% coverage is necessary, to some code is not worth the trouble.  The 100% camp was hit with this rebuttal:

How is the coverage measured?
Is it just checking which code blocks ran during the test?
What about covering different code paths?

Everyone was in favor and there were some interesting insights including an example of “correctness by construction” in Haskell:

…”correctness by construction” (aka “making illegal states unrepresentable”).  This approach relies on a rich type-system (and, at a deeper level, an interesting fact technically known as the “Curry-Howard isomorphism”).  Ideally, when this can be achieved you can completely discharge the need for a lot of unit tests (replacing sort of probabilistic certainty with actual certainty).

Plenty of good links were sent and summarized:

This study found bug reductions of 40-90% with 15-25% coding time added.

Some recommend testability above clarity.

Guidelines on proper coding for testability (in Java).

Miscellany

I heard some talk about an A team being formed to take on a project. I’d like to see the problem these guys can’t solve.

Check out this interesting tool for translating a data model into a class model with proper naming and casing using either Entity Framework or Linq2SQL.

All in all, a quiet week as expected.

ReSharper Withdrawal

ReSharper (R#) is a Swiss Army Knife utility.  It’s an add-in for Visual Studio and it works so seamlessly with the environment, I’m usually not sure if I’m using a ReSharper feature or a Visual Studio feature.  I’ve only been using it a few weeks and I wouldn’t want to work without it.  I know I’ve barely scratched the surface of its features.

My ReSharper license expired and here’s what I missed in the couple hours I was Resharperless:

• Quick delete for sections.
• Auto naming variables similar to their types with proper casing.
• Auto generation of case statement labels.
• Remote editing

Remote editing:  fixing a problem identified in one section of code by modifying another section of code.  For example, as below, when referencing a private enum throws an accessibility warning, you can use the left hand light bulb to correct the problem where it is noted without going directly to the class itself.  This is more useful when the class is in another file and needs a signature or accessibility change.

More great things about Resharper

• Auto adds using namespace statements.
• Auto adds framework references to your project (e.g. WindowsBase)
• Unit test runner – so it replaces TestDriven.Net (sorry TDN, I liked you too)
• Coding hints.  It will offer suggestions on code refactoring
• Move class to its own file.  If you make a class anywhere, you can have R# move it to its own properly named file with one click.  You can also have R# rename the file you’re working on when you rename the class with a convenient click.
• Hot key to create a delegate

Bad things about ReSharper

These are pretty easy to ignore.

• Suppress inspection with comment allows you to stop it from warning you about specific lines of code, but only at the expense of ugly comments in your code
• It keeps offering to convert my Linq queries into Method chains which are usually pretty ugly.

Worst Thing About ReSharper

It’s so good with delegates that its stopping me from learning the proper syntax.

Oh well, I think it’s HL Mencken who said:

Progress consists of increasing the number of things we can do without thinking.

Unfortunately, I can’t find the quote, so maybe I’m wrong.  Does anybody know the source of that quote?  If not, then you can quote me on it.  🙂

Unit Testing — Back to Basics

I’m drinking a lot of cool aid at Lab49 (tastes great, less kludgy).  Its a place where phrases like tail recursion, statistical programming languages, and Dependency Injection/IoC, are regular topics of conversation.  In other words, geek heaven.  So, of course I’m going to use all the tools and tricks I’ve got (otherwise known as best practices) and Unit Testing is fundamental.

What is unit testing? I like to think of it as a bunch of coded functions that test every small part of your program functionality.  But its actually a whole philosophy.

Why should you unit test?  Even Microsoft knows the answer, but here’s a more complete answer — I doubt I need their product though.  Short answer is it greatly helps you deliver and maintain, upgrade and reliably (regression) test software.

The benefits are huge, but the costs are actually minimal.  When a unit test is created in tandem (or before, you TDD purists) with creating code it can be used to test each small piece of the program more quickly and more often without running and clicking through the UI. I feel that writing unit tests is actually less work than doing the testing interactively as I write code.  And writing code that that can be easily unit tested means the code will be more modular and less coupled.  A lower spaghetti factor ;).

It’s been a while since I was using unit testing regularly.  I strayed too far into the realm of custom per project testing frameworks and now I’m happy to start over with with the basic testing frameworks.  Back in 2005, the last time I recall heavily unit testing, there was really only NUnit and TestDriven.net (yes, I’m still just a .Net guy.  Move along Java folks, nothing to see here).  Now there’s MBUnit, XUnit, PUnit, and probably XYZ Unit.   Not to mention Microsoft Unit Testing built into higher versions of Visual Studio.  And check out PEX for automated  creation of tests.  It looks cool but unfortunately is only in version .18, that’s a bit shy of the magic number for me to give it a test drive.

Of course, I started with MS Unit Testing, since its built into Visual Studio.  Its there, why not use it.  Well, its (very) slow to start up, its only there on the higher more incredibly expensive versions of Visual Studio, and its design of running code out of test results subdirectories makes accessing local file resources difficult. The file resource issue was the last straw.  After reviewing the available testing frameworks I chose good old reliable NUnit.  Fifteen minutes later, the tests that I couldn’t make work with MS Test were passing in NUnit — a happy ending.

As a post script, a friend mentioned how ridiculous it is that MS would invest in creating their own testing framework when so many really good open source ones are available.  Many companies contribute to the open source projects rather than building a new less functional wheel.  I couldn’t agree more.  I’m not of the opinion that Microsoft is Evil, well, no more evil than Exxon, but they’ve got it wrong this time.  I don’t see how their crappy unit testing makes the high end Visual Studio any better or encourages anyone to part with an extra buck for it.  Though it might help their FUD campaign, which is evil.