F#

ALT.NET Open Spaces Closing Day Recap

Matthew Podwysocki — Thu, 24 Apr 2008 06:20:38 GMT

In my previous post, I talked about some of the happenings from the day two experience. Day three was only a half day with only two sessions. So, it was best to make the best of times anyhow. Once again, it snowed again, rather heavily at times, so nature's cruel joke on ALT.NET.

Impromptu Sessions

One of the best sessions was an impromptu session with Jeremy Miller on the StoryTeller tool and his future plans for it. If you're not familiar with it, it is a tool used to manage and create automated testing over the FitNesse Dot Net libraries and helps in an acceptance test driven development environment. Anyhow, a number of us managed to corner him at one point during the day and sure enough he had his laptop available. From there, we were able to encourage him to work on it some more as well as learn about where to go from where it is right now. Jeremy covers more about it here. Sometimes these impromtu sessions are some of the more valuable interactions to be had at events such as these.

More Video To Be Had

It seems that almost everyone had a camera at the event. Greg Young and Dave Laribee managed to capture a bit of the sessions on video. That's a great thing because I honestly wish I could have cloned myself and gone to more sessions. Hopefully more of this will be forthcoming. Dave posted Greg Young's fishbowl conversation on Architecture Futures which you can see here.

Other videos that are on this list are from John Lam's IronRuby session, Udi Dahan with ScottGu and Chad Myers talking about Microsoft and Open Source Software and so on. You can find them at the end of Greg's video.

Software Design Has Failed, What Can We Do About It?

Scott Koon, aka LazyCoder, convened with JP Boodhoo a session on how software design has failed us. This turned into a fishbowl conversation as well since there was a lot to be said. The basic points revolved around the large amount of software failures. What causes them? Are they technological issues? People issues? Politics? Many people brought their opinions to bear, and it was interesting that the point that I brought is that at the end of the day, customer satisfaction is the metric that matters. Are we listening to them? In the Agile methodology world, customer satisfaction is the only metric. Yes, we can talk about TDD/BDD, DDD and so on, but are we actually putting software into the hands of the user that they actually want?

I'm not forgetting of course the ideals around mentoring and helping make the team stronger. Those issues are important as well. Do we do pair programming? Do we hold brown bag sessions? All of those suggestions are key to helping grow a stronger team. But, also it helps grow the team as a more cohesive unit that's not afraid to ask questions, pair up and avoid flailing.

F# and Concurrency

Roy Osherove convened a session on concurrency and functional programming as the last topic I was going to attend. When we start to deal with multi-core environments, threading issues come to bear more frequently. Are we utilizing the CPUs to the maximum or are we still just sitting on that one thread, and barely using the machine to its capacity? Those are many of the issues we face. In Software Engineering Radio Episode 14, Ted Neward talks to this very point quite frankly that multi-threaded programming is hard. There are no two ways about it. But, when we talk about functional programming, some of that is solved. Why? Immutability by default is one of the key strong points of FP. Instead, you have to go out of your way to make a value to be mutable. Is this something we'll see in C# 4.0? Spec# has something to say about it. And once again, another topic for discussion. I keep putting these things on my plate...

Anyhow, Harry Pierson and I helped run this session. Harry had some of his parsing code that he has posted on his blog to show off. I think that did the trick well to show some advanced things such as high order functions, pattern matching, anonymous functions and so on. Instead, if you wish to learn more, I'll probably cover it here in some detail, but you can check chapter 13 of Don Syme's "Expert F#" book to learn more in the mean time.

Action Items

Some action items came up from this event that I think are rather important. Because ALT.NET is a community looking to improve itself, there are naturally some things that help. Here are a few that I can think of:

Keep the conversation going
Just because the conference ended doesn't mean the conversations that started there have to.
Start a local group
After the session was done, the altdotnet mailing list came alive with people wanting to create that ALT.NET groups like I did in DC, Brian Donahue did in Philly and Jeremy Jarrell did in Pittsburgh.
Support the community
Ray Houston laid out a challenge for those who use Open Source products to donate to them. This doesn't mean only money, but time as well. Many projects are in need of some assistance, and all it takes is for someone to ask.
Challenge Assumptions and Bring Change
It was said best during the conference "If you can't change your job, change your job". Don't let these discussions that happened here just stay there. Bring them to your work place, bring change for the better. Question why things are done the way they are.

Wrapping it Up

I'm glad to have been a part of this event in Seattle. It couldn't have been with a better bunch of people who are willing to better themselves, challenge themselves and their assumptions and bring change to the developer community. There was a lot to learn this past weekend and each conversation brought up a new angle. Until next time...

NOVARUG with Dave Thomas (PragDave) Recap

Matthew Podwysocki — Thu, 17 Apr 2008 15:29:31 GMT

Last night I attended the Northern Virginia Ruby Users Group (NovaRUG) meeting in Reston last night with Dave Thomas (PragDave) and Chad Fowler. It was a completely packed house and the temperatures were a bit hight in the room, but it was well worth the sweating to attend.

Paul Barry presented first on Merb and gave a really good demonstration of some of the capabilities in comparison to Ruby on Rails. If you're not familiar with Merb, it is a lightweight Model View Controller framework written in Ruby. It was written by Ezra Zygmuntowicz in response to trying and giving up on making Ruby on Rails thread safe. You can find his presentation materials here.

It was mentioned that there will be a Ruby conference in the Northern Virginia area upcoming I'd like to see if we can get some IronRuby in there instead of all those Java guys with JRuby. We'll see what happens, but for right now, everything seems to be in flux. Stay tuned!

Next up, Dave Thomas talked about the Ruby object model with a very good presentation. Below you can find some of my pictures I took from the event. Forgive the quality of the images, but you can tell that it was a crowded place! Anyhow, it was a really good talk about the object model, how the scoping of self and the resolution of classes and methods are done deep down in Ruby. It was an excellent presentation and I was definitely excited by his passion for the community and the technology.

First we have Dave talking about the inheritance chain of Ruby objects.

Then here's Dave talking about the method resolution.

I had a chance to chat with Dave afterwards on F# as he has been looking into OCaml lately, where F# got most of its functionality from. It's his hope that F# succeeds and I ultimately think it will. So, I told him to give it a try. Anyhow, it was a great night and good to reach out to the community. The DC area has a pretty rich community of .NET, Ruby and Java programmers that's really refreshing to see. Until next time...

Metaprogramming in F#

Matthew Podwysocki — Wed, 16 Apr 2008 21:19:20 GMT

Tonight I will be heading to the Northern Virginia Ruby Users Group (NoVARUG) meeting tonight with Dave Thomas (PragDave) talking about metaprogramming in Ruby. Should be a great time and I'm sure it will be full tonight. For those interested in some introduction to metaprogramming in Ruby, here's a good link to help get you started.

Metaprogramming in F#?

One of the many things that has interested me in F# is that it was originally written as a language to write other languages. This of course leads me to a discussion of F# and metaprogramming. Is it a fit? There are a couple of links well worth visiting and then at a future date, we'll come back to the subject.

Before the links, most of the language oriented stuff comes from quotations. Quotations are a little block of code which turns a particular piece of code into an expression tree. This language tree can then be transformed, optimized and even compiled into different languages. There are two types of these quotations, raw and typed. Typed Quotations contain static typing information whereas the raw do not. For a good introduction to these, check out Tomas Petricek's post here.

Leveraging Meta-Programming Components with F# - Don Syme
Talks about F# with Quotations and LINQ expressions for expressing metaprogramming in F#
F# metaprogramming and classes - Tomas Petricek
Talks about Class Quotations and basic metaprogramming capabilities in F# and its limitations

I hope when I get a further chance, I'll dig into it a bit more here. Until next time...

Adventures in F# - F# 101 Part 8 (Mutables and Reference Cells)

Matthew Podwysocki — Tue, 15 Apr 2008 23:08:37 GMT

Time for another adventure in F#, covering some of the basics of functional programming and F# in particular. Today we'll manage to look more at regular .NET integration and .NET programming. With the previous efforts, we've looked more at functional programming and in turn F# specific things, but want to show that you can do anything normally in F# that you can in C#. To me, F# is the perfect all-purpose language because it can do a lot of the things C# can do, but in turn, F# can do things much more elegantly than C# can, such as Pattern Matching.

Where We Are

Before we begin today, let's catch up to where we are today:

Today's topic will be covering imperative and object oriented programming in F#. There is a lot to cover, so let's get started. But there are a few administrative things to get out of the way first.

Learning F# ala Ted Neward?

Ted Neward recently announced on DotNetRocks Episode 332 that he's in the process of creating a class for F# for Pluralsight. That should be interesting to those who are interested in this series, as well as F# in general. Right now the community is rather small, so efforts like this should be rather rewarding I would hope. Ted's a pretty brilliant guy, so I'd imagine only the best. I'm hoping more details come out soon.

Pattern Matching in C#

Part of this series is intended to bring such concepts as Pattern Matching, Currying and other Functional Programming concepts to the C# developer. After all, the more C# language evolves, the more it seems to fall into the Functional Programming category. In previous posts, I showed how to relate currying to C# and it was less elegant than F# to say the least.

But, let's look at Pattern Matching. Bart De Smet has been posting recently on his blog about bringing the beauty of pattern matching to C#. So far it's been a good six posts into it and I urge you to go ahead and take a look at this series.

But when you read the series, it's all about getting into the low level and compiling expression trees to make the same simple beauty that is F#. Sure, it can be done in C#, but nowhere near as elegant. Performance is another issue that comes to mind with these.

Imperative Programming in F#

This section I'll lay out some of the basics of imperative style programming before I get into the full object oriented approach to programming. So, we'll cover just a few topics and then I'll feel comfortable moving onto the real parts of creating classes and such. We'll cover such things as void types and mutability in this section.

The unit Type

One of the first things I forgot to mention when describing F# functions and values in the unit type. Think of this as the void type in C# that you are used to. It's the type that doesn't accept or return a value. First, let's look at the typical C# program with the void type for Hello World.

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }

Now, let's go ahead and look at it from the F# perspective.

#light

let main() =

  printfn "Hello World"

main()

As you will see when you hover over our code is that it is a unit type. That in itself isn't all that interesting. But, what we'll run into is problems when functions return a value, but we're not all that interested in them. What happens? Well, F# will complain that your return value isn't compatible with the unit type, which is essentially true. So, how do you get around that? Let's walk through a simple unit test of a Stack written in F# and unit testing with the xUnit.net framework.

#light

#R @"D:\Tools\xunit-build-1252\xunit.dll"

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop() =

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> stack.Pop() |> ignore )

The real interesting part you should pay attention to is the last line. As you can see, I am using the forward operator to indicate that I really don't care what the function returns, just that I'm interested in that it executes. This is most likely during such functions that have some sort of side effect to them. I could also use the ignore function instead of the forward operator such as this:

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> ignore(stack.Pop()) )

This is very helpful in these cases where we really don't care about the return value, instead want to mutate the state of our given object, such as removing a value from a collection and so on.

Mutables

As I said in many posts before, by default all "variables" by which I mean values in F# are immutable. This is a standard in functional programming and all in the ML family. You can easily redefine a value by using the let keyword, but not actually mutate its state. But, since F# is a multi-purpose language on the .NET platform, mutable state can be had. To take advantage of this, mark your value as mutable. Then to change the value, just use the <- operator to reassign the value. Below is a simple example of this:

#light

let mutable answer = 42

printfn "Answer is %i" answer

answer <- 8

printfn "Answer is %i" answer

A key difference from the reassignment is that you cannot change the value type. Whereas I can redefine answer by keep using the let keyword, I can only keep my answer in this above example of the int type.

This can also apply to record types as well where you can change the fields. In the last installment, we talked about record types. Well, by default there as well, the fields for the record type are immutable. But, as with before, that can be changed. I of course like to caution people that mutable state takes a lot of the value proposition away from the side effect free programming that you gain with F# by default. But, nevertheless, you can still do it as noted below:

#light

type Person = { FirstName : string; mutable LastName : string; mutable IsMarried : bool }

let friend = { FirstName = "Courtney"; LastName = "Cox"; IsMarried = false }

friend.LastName <- "Cox-Arquette"

friend.IsMarried <- true

What I was able to do was define a Person record and change a couple of fields while using the <- operator and defining the fields as mutable. Yes, I could have used some scientific calculation or something, but this was easy.

Reference Cells

The last thing I want to touch on in this post is reference cells. You can think of these much as pointers in other languages or reference types. These of course can be of any type. The idea behind using these is to make updating fields as easy as possible. As with mutable fields, you cannot change the type once it has been assigned. To use these, you need to remember three basic operators

ref - Allocates a reference cell
:= - Mutates a reference cell
! - Reads the reference cell

Below is a quick example of mutation through reference cells:

#light

let x = ref 2

x := !x + 25

printfn "%i" !x

What the code example above lets me do is define a reference to the number 2. Then I can change that reference by reading the current x value and adding 25. Then I mutate the existing x value with the result.

Conclusion

This is just meant to be a brief overview to some imperative programming constructs that you might see in .NET, Java, C, C++ and so on. F# is a first class language all the way with constructs that support these things as well as your normal functional programming constructs. I hope we get to cover some of this at ALT.NET Open Spaces, Seattle at some point because I'm sure a lot of people will be interested. Until next time...

Relooking at xUnit.net RC2

Matthew Podwysocki — Fri, 04 Apr 2008 22:34:24 GMT

UPDATE: More posts on the subject

xUnit.net RC3 Just Released

Earlier this week, I wrote about the latest release of xUnit.net RC2. Since that time, Brad Wilson and Jim Newkirk released a new version to fix some of the issues with regards to TestDriven.NET integration and ASP.NET MVC integration. You can read more about the issues here. As always you can get the latest bits here.

The Installer

If you browse to the releases page of xUnit.net, you will notice an installer. This installer will help integrate xUnit.net with Resharper 3.1 for Visual Studio 2005 and 2008, TestDriven.NET and ASP.NET MVC. Just click the installer and a screen like below will show. Note that I have Resharper 4.0 nightly builds instead of 3.1, so those features aren't activated just yet, unfortunately.

Since I didn't have anything else but ASP.NET MVC Preview 2 installed, that's all I got enabled. It only takes a few seconds to enable.

ASP.NET MVC

Now that I got the ASP.NET MVC plugin installed for xUnit, I can go ahead and open Visual Studio 2008 and create a new ASP.NET MVC application. When it automatically creates the test project for me, I have the option now of using xUnit.net instead of that lesser one that came in here by default.

Once I do that, it will create some tests of the HomeController and Routes by default as noted below:

But in order for this to work out of the box, there is some work you need to do. Your tests will not compile by default because you need to change the namespace includes on top to include your application's namespace. Not a huge issue mind you, but a little more work than usual. Here's what it will look like:

using MVC_APPLICATION_NAMESPACE.Controllers; // This using directive needs to point to the namespace of your MVC project
using Xunit;
 
namespace PetShopTests.Controllers
{
    public class HomeControllerFacts
    {
        public class Index
        {
            [Fact]
            public void RendersTheIndexView()
            {
                TestableHomeController controller = new TestableHomeController();
 
                controller.Index();
 
                Assert.Equal("Index", controller.RenderView_ViewName);
            }
        }

So, all you need to do is replace the MVC_APPLICATION_NAMESPACE with your own namespace and problem solved! But out of the box, you have some working unit tests and some good guidance on how to get started. If you're curious on how the integration actually works, check out this post here.

GUI Runner

As Brad had stated earlier, there is a simple, yet effective GUI runner for xUnit.net. So far there's not much to it, other than to load an assembly and run all associated tests. To give you an example, I wrote some F# code and now I want to run some tests against it. So, here is the code I used for these simple tests. Yes, you can go ahead and yell at me for doing OO things in a functional language, but it's here to prove a point that you can.

#light

#R @"E:\Tools\xunit-build-1223-samples\Samples\xunit\xunit.dll" 

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop = 

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]   

let NoElementsShouldBeEmpty () =

  let stack = new Stack<string>()

  Assert.True(stack.IsEmpty)
 
[<Fact>]

let PushAnElementShouldNotBeEmpty() =

  let stack = new Stack<string>()

  stack.Push("first element")

  Assert.False(stack.IsEmpty)

And now, open the xunit.gui.exe and select your assembly you want to run. I chose my fsharpsamples.dll that I've been working with on my F# samples. Now, let's give these two tests a run to see how they do.

As you can see, not much information is given to me other than the number of passed tests, the time taken and my assembly under test. Not much information, but enough to get started.

Conclusion

As you can see, a bit of progress has been made on xUnit.net and here's hoping the version 1.0 full release is coming soon. As I look at it more and more, I'm definitely starting to like it. I haven't had to create as many extensions as I would have to do with MSTest such as Assert.Throws<T> and so on. So, I encourage you to go ahead and once again, give it a look and give feedback to the team. Until next time...

Adventures in F# - F# 101 Part 7 (Creating Types)

Matthew Podwysocki — Thu, 03 Apr 2008 23:37:44 GMT

Time for another adventure in F#, covering some of the basics of functional programming and F# in particular. This is intended at looking at the foundations of F# as well as how it relates to .NET and IL on the back end. I realize I need to spread more of the F# goodness around, so I'm hoping that I can work to bring it at least to the FringeDC user group. Their main meetings are every three months, so hopefully I'll get some time in to do that. Once I get that set up, I'll be sure to let everyone know.

Where We Are

Before we begin today, let's catch up to where we are today:

Today's topic will be covering creating custom types in F#. There is a lot to cover, so let's get started.

Types of Types?

If you're familiar with OCaml, the type system in F# should look rather familiar. For a brief introduction to how OCaml works, check out Dr. Jon Harrop's OCaml for Scientists introduction here. We have several categories of types in base F#. The first category is the tuples or records, and the second type are unions.

Tuples

The most simple type in F# is a tuple. A tuple is a compound type composed of a fixed sequence of other types. Each value is separated by a comma and can be referred to by a single identifier. The values from the tuple can be retrieved by putting commas on the other side of the equals. Below is a quick sample of this concept:

#light

let coin = "heads", "tails"

let c1, _ = coin

let _, c2 = coin

print_string c1

print_string c2

What I did to look up the values was to use the _ to indicate I wasn't interested in the other values. Hence my c1 got me heads and c2 got me tails. As always, I'm always curious how it compiles down to C# and how it gets represented in IL, so let's take a look at the coin type that I created.

Nothing really fancy, as we created a tuple of type string and string which held our "heads" and "tails" value. Like I said before, tuples are the simplest type in F#. In fact, as you saw above I didn't even need to use the type keyword to specify I was creating a new type. However, I can choose to use the type keyword so that I can create a type alias which can be very useful for method signature constraint. Below is a simple sample of doing that.

#light

type Point3D = double * double * double

let pointPrinter(p : Point3D) =

  let x, y, z = p in 

  "x:" + x.ToString() + " y:" + y.ToString() + " z:" + z.ToString() 

let pointString = pointPrinter(2.3, 5.3, 9.8)

print_string pointString

As you can see from above, I created a 3D point which contains an x, y and z axis. Then I constrained the pointPrinter function to take that as a constraint so that I can format it properly. Then of course I do all the great things I normally would do by printing it out to the console. But, if you want to take a look at what this pointPrinter function does behind the scenes, wonder no longer.

Quite an interesting mouthful, I must admit, but that's what you get when you deal with immutable types such as strings.

Records

Record types are also a user defined data structure within F#. These are similar to tuples, but differ because each piece of data (field) inside a record must be named as well as the keyword type must be used. Think of this much as a .NET class with simple properties. What's interesting is that these fields that it creates for us aren't forced to be unique. Let's go ahead and show a simple example of a Person record that we may want to create.

#light

open System

type Person = 

  {

    FirstName : string;

    MiddleName : string;

    LastName : string;

    DateOfBirth : DateTime;

  }

let person1 = { FirstName="Robert"; MiddleName="William"; LastName="Jones"; DateOfBirth = new DateTime(1960, 12, 12); }

let person2 = 

  { new Person

    with FirstName = "William"

    and MiddleName = "Franklin"

    and LastName = "Smith" 

    and DateOfBirth = new DateTime(1970, 1, 23) 

  }

print_string person1.FirstName
print_string person2.FirstName

What I have done is created a Person record with a FirstName, MiddleName, LastName and a DateOfBirth field. Pretty simple. Now, we have two ways of creating an instance of this type. When I created person1, I just simply just set each field separated by a semicolon. On the other hand, since I'm not explicitly naming a type, there could be conflicts due to multiple types containing the same fields. Should I want to be more explicit, I can specify it using the longhand way with using the new operator and setting each property with the with keyword and followed by an and on each subsequent line to fill in all the other values. Such a conflict would look like this:

#light

type point2D = { X:double; Y:double }

type coordinate2D = { X:double; Y:double }

let myPoint = { X = 2.5; Y = 3.2; }

What the above sample will default to is that myPoint will be of type coordinate2D. Hover over and let Intellisense do its magic. Interesting, huh? That's why we should be explicit about our data structures should something like this arise.

Discriminated Unions

The next category of F# type that will be discussed is the discriminated union. This type is a data structure that can bring together values but have different meanings or structures. Only one of these types can be used at once, however. Think of it more of a type which is almost "case" like. Each piece of that is called a discriminator. A quick example of this would be something like distance where it could be measured in miles or kilometers, but not both at the same time. The structure of this data is the same, but have different meanings to the program.

Let's look at some quick examples of this:

#light

type Distance = 

  | Kilometer of  double

  | Mile of double

let distance1 = Mile 26.2

let distance2 = Kilometer 10.0

let convertDistanceToMile x =

  match x with

  | Mile x -> x

  | Kilometer x -> x * 1.609344

let convertDistanceToKilometer x =

  match x with

  | Mile x -> x * 0.621371192

  | Kilometer x -> x

let convertedDistance1 = convertDistanceToKilometer distance1

let convertedDistance2 = convertDistanceToMile distance2

As you can see from above, I created a Distance discriminated union that defines both miles and kilometers. Both discriminators are of type double. So, I wrote a function to convert from one to the other. It's just a simple pattern matching statement. If you've read my previous posts, you should be caught up to date with this.

I could also parameterize this data differently, meaning that each discriminator can hold a different value.

#light

type Carrier = string

type Route = int

type Make = string

type Model = string

type Year = int

type ModeOfTransport =

  | Airplane of  Carrier * Route

  | Bus of Carrier * Route

  | Car of Make * Model

let mode1 = Car("Audi", "A4")

let mode2 = Airplane("United", 222)

As you can see, I type aliased a few things such as Carrier, Route, Make, Model and so on. After that, I defined my ModeOfTransport to be by bus, car or airplane. A pretty simple example.

I can also specify the type of arguments later, by specifying them as generics. One of them you may have already run across is the option type. To declare one, just use the <'a> or whichever letter you so choose. Let do a recursive example of a tree.

#light

type Tree<'t> =

  | TreeNode of  't Tree * 't Tree

  | TreeValue of  't

let tree =

  TreeNode(

    TreeNode(TreeValue 0, TreeValue 1),

    TreeNode(TreeValue 2, TreeValue 3))

From the above statement, I created a tree of nodes quite easily using this union type. These types can get complicated quickly, however when you get into language oriented programming, so we're just dipping our toes in at the moment.

.NET Types?

Yes, you can also create .NET types as well just as easily, although with a few major details. For example, the mutable types which is not by default in F#. I'll cover that in the next post.

Conclusion

As you can see, there are a few basic types in F#. They are mostly for holding analytical data, traversing them and so on. These are interesting and serve as the basis of what you will do in F# when you need to store and analyze data, especially custom types. In the next installment, I hope to cover some .NET specific topics such as creating .NET types. Until next time...

Covering NUnit 2.4.7

Matthew Podwysocki — Tue, 01 Apr 2008 21:34:37 GMT

It's interesting that a flurry of releases of testing frameworks have been released lately with Gallio, xUnit.net and of course NUnit. Charlie Poole recently announced on a lot of the discussion boards I belong to recently that NUnit 2.4.7 was recently released. You can read all about what's been added here with the release notes.

What's New and Interesting?

What's interesting about this release? Well, NUnit no longer depends on log4net, thus getting rid of some dependency issues with regards to the applications under test. What's also interesting is that addition of the RowTest extension to allow multiple sets of arguments to be given to a test. This is the first one that's ever been incorporated into the core of NUnit.

Static Tests in NUnit?

As Andy Stopford noted in my blog yesterday regarding xUnit.net, Charlie recently checked in code to allow static methods for static methods to be tests as well as Setup and TearDown to be static as well. Jim Newkirk, the man behind NUnit and co-creator of xUnit.net, favors that approach of allowing statics. To me, I don't care as much with regards to Startup and TearDown with statics as most of my statics for testing F# is side effect free programming. As it should be with functional programming. Anyhow, what I'd like to see in NUnit is the support for something that I can do in xUnit.net:

#light

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.core.dll"

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.framework.dll"

open NUnit.Framework

let rec fib n =

  match n with 

  | 0 | 1 ->  0

  | n -> fib(n-2) + fib(n-1)

  | n when n < 0 -> failwith "Cannot be less than zero"

[<TestFixture>]

let FibOfOneShouldReturnZero() =

  let fibResult = fib(1)

  Assert.AreEqual(fibResult, 0)

If I saw something like this, I'd be a happy man. But until then, I can dream...

Conclusion

Go ahead and pick up your copy today of NUnit. It's been the old standby for many of my projects throughout my career and served me quite well. Next time I'll cover Gallio a little bit as I have neglected it, but it's a huge release.