In a recent post I mentioned that I started learning F#. Over the past few weeks I’ve really started falling in love with the language. Coincidentally, my team has been incorporating more test-driven development (TDD) into our process and as part of that training Roy Osherov’s TDD Kata 1 was mentioned. I immediately thought “Hey! Let me try doing that in F# and see how it goes!” I’ve run through the kata more than a few times now and I’m ready to share my experience with the world. Continue reading
A few weeks ago I started learning F#. As I moved from the simple examples that were easily executable in F# Interactive or LINQPad though I found myself wanting to write formal unit tests to make sure I was understanding the concepts correctly. I decided to write my tests in F# for more practice and because its syntax makes it an attractive choice but in order to keep the learning curve under control a bit I thought it best to stick with a familiar test framework – NUnit. Using NUnit with F# is pretty trivial but being so new to the language I ran into a few small obstacles.
In order to use NUnit we need to import the types from the NUnit.Framework namespace. Importing the types is accomplished with the open keyword which looks and behaves much like the using directive in C#.
Don’t get too excited yet though because the compiler is probably yelling at you.
Most F# tutorials that I’ve seen provide examples that are easily run within F# Interactive (FSI), LINQPad, or a single F# Application (exe) project. They generally only include a few types and almost never span multiple files let alone multiple assemblies or languages. This is great for introducing concepts but as soon as you move to a more complex library project (like one for testing) the compiler will politely inform you of a problem depending on where you’ve placed the declaration:
Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. ‘namespace SomeNamespace.SubNamespace’ or ‘module SomeNamespace.SomeModule’
If you’ve placed the directive at the beginning of the file before declaring a namespace or declaration you’ll see the above error. To fix this problem I like to take the namespace route because I’m just trying to group my testing types and it follows the organization pattern I’d be using were I writing the tests in C#.
namespace StringCalculatorKata.Logic.Tests open NUnit.Framework  type StringCalculatorTests() =  member x.Add_EmptyString_ReturnsZero() = // Test Code Omitted [<TestCase("1", Result=1)>] [<TestCase("2", Result=2)>] member x.Add_SingleNumber_ReturnsThatNumber calcString = // Test Code Omitted
With the types imported we can identify our fixtures and tests. The good news is that we accomplish this with attributes just like with other .NET languages. The bad news is that although it’s simple, it’s not immediately obvious. If you’re reading this you should already know that TestFixtureAttribute applies to the classes that hold your tests and that TestAttribute and TestCaseAttribute identify tests. But how does that translate to F#?
One answer is to define a type and decorate it with the appropriate attributes. You’ll want to make sure you’re applying the test attributes to member bindings rather than let bindings here because let bindings compile to internal members whereas member bindings compile to public members by default.
 type StringCalculatorTests() =  member x.Add_EmptyString_ReturnsZero() = // Test Code Omitted [<TestCase("1", Result=1)>] [<TestCase("2", Result=2)>] member x.Add_SingleNumber_ReturnsThatNumber calcString = // Test Code Omitted
Were you aware though that since .NET 2.0 you could apply TestFixtureAttribute to a static class as well? If you prefer this approach you can define your fixture as a module since modules compile down to static classes.
 module StringCalculatorTests =  let Add_EmptyString_ReturnsZero() = // Test Code Omitted [<TestCase("1", Result=1)>] [<TestCase("2", Result=2)>] let Add_SingleNumber_ReturnsThatNumber calcString = // Test Code Omitted
Aside from being a module definition, notice that the attributes are applied to let bindings in the module. Module level let bindings compile to public static members by default.
So far I’ve been careful to avoid including assertions in the sample code. Not to worry, assertions in F# are the same as they’d be in any other language but you do need to be aware of a syntactic nuance that affects many of the assertion methods.
In short, the compiler’s overload resolution mechanism requires you call them using a syntactic tuple form (syntax that looks like a tuple but isn’t) rather than the curried form that’s so common in F#. This means that instead of separating the individual parameters with spaces you need to call the method like you would in C#:
type StringCalculatorTests() =  member x.Add_EmptyString_ReturnsZero() = let calc = new StringCalculator() let result = calc.Add "" Assert.That(0, Is.EqualTo 0)
Of course, if you’re using TestCaseAttribute with the optional Result parameter you’ll be able to eliminate the manual assertion altogether in many cases:
 type StringCalculatorTests() = [<TestCase("1", Result=1)>] [<TestCase("2", Result=2)>] member x.Add_SingleNumber_ReturnsThatNumber calcString = let calc = new StringCalculator() calc.Add calcString
If you’re a fan of the Microsoft Moles framework you’ve probably heard that it’s being included in Visual Studio 2012 as Microsoft Fakes. As I was preparing my talk covering this isolation framework I noted some of the key differences between the two. Rather than going back and updating my original post regarding Moles (much of which is still applicable even with terminology changes) I thought I’d list those differences here. So without further ado:
- Assembly generation is driven by a .fakes file rather than a .moles file
- Isolation types are placed in a .Fakes assembly and .Fakes namespace
- Shim types replace Mole types
- Stub types are prefixed with “Stub”
- Shim types are prefixed with “Shim”
- ShimsContext replaces HostTypeAttribute for enabling profiling
- Profiling occurs in the IntelliTrace profiler rather than the Moles profiler
- Fakes allows shims for static constructors whereas Moles allowed erasing static constructors through an assembly attribute
- Fakes does not provide any support for finalizers whereas Moles allowed erasing finalizers through an assembly attribute
- Moles allowed controlling whether the profiler would run as a 32-bit or 64-bit process but this is now handled entirely by the IntelliTrace profiler
- The “classes” filter attribute was removed.
- Fakes supports isolating auto-implemented properties
- Fakes play much nicer with testing frameworks other than MSTest when run through Visual Studio
If you’re interested in learning about the Fakes framework (formerly Microsoft Moles) that’s included with Visual Studio 2012 you have two opportunities to do so this week. Those in Fort Wayne, Indiana should attend tomorrow’s (June 12) NUFW meeting. If Indianapolis is more convenient, feel free to attend Thursday’s IndyNDA meeting instead. Of course, if you just want to heckle me attending both is also an option!
If either of these events interest you please check the appropriate group’s site for logistics. I hope to see you there!
Ok, this should be the last post about speaking engagements for a while ;) I have something else in the works that’s going to take a lot of my attention for some time (more on that on Friday).
I’m pleased to announce that I’ll be returning to Fort Wayne in June to talk about the Microsoft Fakes framework (formerly the Moles framework). In this talk I’ll introduce the Fakes framework, discuss the use cases for the different isolation techniques, and show how to take advantage of them in your unit tests.
The meeting will be held on Tuesday, June 12 at the Northeast Indiana Innovation Center. Pizza and drinks will be available at 6:00 with the presentation starting at 6:30. For more information please check the NUFW site.
I’ve been using TortoiseSVN for years. One place I’ve found it lacking in the past though was when I wanted to remove unversioned files from my working copy. This has generally been a nuisance but I’ve dealt with it. A few days ago, I needed to recover from a merge gone wrong and got serious about finding a better way.
It’s the second week of February so if you read this blog with any frequency you know what that means. That’s right, IndyNDA is this Thursday (9 February)! This month we’re fortunate to have Phil Japikse returning to discuss testing legacy code.
Michael Feathers defines Legacy Code as any code that doesn’t have automated tests, and you agree that automated tests are an important facet of successful software development. Then it happens – you get your next assignment, and it’s your worst nightmare! You have to maintain and enhance a large application that has no tests in place, and there are parts that are just plain scary. Where do you start? Traditional Test Driven Development techniques don’t typically work, since they focus on an inside-out development paradigm.
I will show you the patterns and practices that will help you turn the scary big ball of mud into a tested code base.
I’m excited to have Phil back. I’ve heard him speak many times and have always found his talks both informative and entertaining.
This month we’re meeting in the 2nd floor conference room at 900 E. 96th Street. Registration begins at 5:30 and the main event kicks off at 6:00. Snacks and soft drinks will be provided.
I hope to see you there!
A few nights ago I was over at my local Fry’s looking for a battery charger and a new Compact Flash card for my camera when I stumbled upon the book Driving Technical Change by Terrance Ryan. I think it was the distinctive look of a Pragmatic Bookshelf title that caught my eye. I picked it up, glanced over a few pages, said “what the hell,” and bought it. The book weighs in a bit under 150 pages so it’s a pretty quick read. Even with my slow reading pace and note taking I managed to make it through the book in just a few hours.
3/27/2012 Update: According to the Moles page, the Moles framework has been integrated into Visual Studio 11 as the Fakes framework and Moles is no longer under active development. After a quick review of the changes it appears that most of this guide still applies but there are a few changes to be aware of:
- Mole types are now referred to as Shim types
- The configuration file now has a .fakes extension
- The generated types are now placed in a .Fakes namespace (i.e.: System.Fakes)
6/25/2012 Update: In preparation for my Faking It talk covering the Fakes framework I compiled a list of the notable differences between Moles and Fakes. There are quite a few more than I listed above so if you’re using this post as an introduction to either framework you’ll probably want to look them over.
Despite having been around for several years I hadn’t heard about Microsoft’s Moles framework until a few months ago when one of my teammates mentioned it during the 2011 Indy GiveCamp. I was interested in learning more about it at the time but given how we were running on caffeine I’m not surprised I forgot about it until he mentioned it again a few weeks ago. This time I was much more alert and started reading about it almost immediately. After seeing what Moles offered and not finding much in the way of resources for it on the Web I knew I needed to spread the word.
Recently I’ve been working with a third party component vendor to resolve a defect. They requested that I create a sample project illustrating the issue and send it to them as a zip archive. Building the project was easy but I didn’t want to send all of the extra stuff that goes along with it. In other words, I wanted a snapshot of the current revision but without the source control bindings. I knew how to do this with Subversion but how did Mercurial handle it?