Back to Questions
2.0k
views5
comments
VS 2008 unit testing
f#testing

Has anyone tried Visual Studios 2008 unittesting with F# ? You can create a TestClass with something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

open Microsoft.VisualStudio.TestTools.UnitTesting;

#I @"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies"

#R @"Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"

[<TestClass()>]
type TestCaseUtil = class
    new() = {}  

    [<TestMethod()>]
    member x.sums() = 
        Assert.AreEqual<int>(9, sum [2..4])
        Assert.AreEqual<int>(9, 2+3+4)
end

Unfortunately, VS doesn't pickup the tests...

.

I haven't used the VS 2008 built-in unit testing facility. So, the rest of the post is actually about NUnit...

I've used NUnit and it works quite well if you don't want to roll your own testing framework. There is at least 1 thread on NUnit on HubFS that is active at the moment. There's also an old video I came across (from when .NET 2.0 was just coming out) that talks about using NUnit and F#. You can find it at [link:video.google.com]. This video is what actually got me interested in using F# with NUnit. In addition, there's a very small section in Foundations of F# that talks about using F# with NUnit.

Since NUnit is a standard unit-testing library that works with most (if not all) of the .NET languages, it seems like the best choice, esp. for multi-language projects.

Regards,

z.

By on 1/3/2008 4:24 PM ()

I have not yet tried using VS2008 unit testing, but as zakaluka mentioned, nunit is a great unit testing tool. I posted this in a different forum thread, hope it helps!

[link:cs.hubfs.net]

By on 1/4/2008 4:22 PM ()

I like NUnit and my post is inspired by your thread.

However, the MS builtin testing offers some advantages like quck debugging.

By on 1/5/2008 6:13 AM ()

Hi Ray,

this isn't an answer to your question but a suggestion to try a different approach to unit testing with F#.

IMHO the typical unit testing tools are rather clumsy to use and probably unnecessary for all but the largest projects. A more lightweight approach to testing is to define some helper functions that simply raise an exception when a tested condition doesn't hold. For example:

1
2
3
4
5
6
7
8
9
10

 
let fail ()  = failwith "Test error"
let Equal a b = if a <> b then fail()
let Larger a b = if a <= b then fail()

let myTests() = 
    sum [2..4] |> Equal 9
    2 + 3 + 4 |> Larger 8
    // ...

Now all you need is to compile and execute your test code. If an exception is raised you use the debugger to step back on the call stack and see what went wrong. This approach has the advantage that you can use all the power of F# to organise your tests in functions, compose tests and parametrise tests. The only situation where this approach might lead to problems is when you can't immediately fix bugs and have multiple expected failures that you all want to log with precise locations. That shouldn't be an issue for small to medium size projects, though.

By on 1/3/2008 4:05 AM ()

My main concern is that the Attributes are not being picked up.

Your example looks much nicer IMHO; mine requires a class and such...
However, I miss the reassurance that comes with automated regression testing.
Perhaps we can have both with something like this:

1
2
3
4
5
6

[<TestMethod()><TestMethod()>]
let myTests() = 
    sum [2..4] |> Equal 9
    2 + 3 + 4 |> Larger 8
    // ...
</TestMethod()>
By on 1/5/2008 6:21 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper