tag:blogger.com,1999:blog-45854643096987082372024-02-20T22:27:03.636-05:00Consumed by CodeCode is a predator and I'm its prey.Ray Vernagushttp://www.blogger.com/profile/12678750838556666846noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4585464309698708237.post-84884266513005131262009-12-14T22:29:00.005-05:002009-12-15T11:01:50.628-05:00Towards FsUnit 1.0<p>I have been giving a lot of consideration recently to an <a href="http://code.google.com/p/fsunit/">FsUnit</a> 1.0 release and the direction of the project. The 0.6 release was meant to steer the project more in the direction of Behavioral-Driven Development but there is already a much better project out there for F# and BDD, <a href="http://code.google.com/p/natural/">NaturalSpec</a>. </p> <p>FsUnit 1.0 will instead be geared for more classical unit-testing and it now has two explicit goals: 1) to make unit-testing with F# more functional in nature and 2) to leverage existing unit-testing frameworks while at the same time exploring new possibilities offered by the F# language.</p> <p>The target audience for this project is the F# developer (new and veteran alike) who wishes to use the same unit-testing framework that they’re already knowledgeable about: <a href="http://www.nunit.org/index.php">NUnit</a>, <a href="http://www.mbunit.com/">MbUnit</a>, <a href="http://www.codeplex.com/xunit">xUnit</a>, and MsTest. The new 0.9 release supports only NUnit but the others will be added soon.</p> <p>The core syntax is pretty much the same as it has always been:</p> <pre class="f#" name="code">1 |> should equal 1<br /><br />1 |> should not (equal 2)<br /><br />[1] |> should contain 1<br /><br />true |> should be True</pre><p>But tests are once again contained within a test fixture and executed with a test runner. Here is the code for one of the project examples (UPDATE: removed non-standard use of self-identifier per reader's comments. Thanks, Alan!):</p><pre class="f#" name="code">type LightBulb(state) =<br /> member x.On = state<br /> override x.ToString() =<br /> match x.On with<br /> | true -> "On"<br /> | false -> "Off"<br /><br />[<TestFixture>] <br />type ``Given a LightBulb that has had its state set to true`` ()=<br /> let lightBulb = new LightBulb(true)<br /><br /> [<Test>] member test.<br /> ``when I ask whether it is On it answers true.`` ()=<br /> lightBulb.On |> should be True<br /><br /> [<Test>] member test.<br /> ``when I convert it to a string it becomes "On".`` ()=<br /> string lightBulb |> should equal "On"<br /><br />[<TestFixture>]<br />type ``Given a LightBulb that has had its state set to false`` ()=<br /> let lightBulb = new LightBulb(false)<br /> <br /> [<Test>] member test.<br /> ``when I ask whether it is On it answers false.`` ()=<br /> lightBulb.On |> should be False<br /> <br /> [<Test>] member test.<br /> ``when I convert it to a string it becomes "Off".`` ()=<br /> string lightBulb |> should equal "Off"</pre><p>I’m curious as to what people think about the use of back-ticked method names. I, for one, find it very helpful to be able to write in plain prose instead of CamelCase’d or snake_case’d method names.</p><p>Stay tuned to this blog for more information as FsUnit reaches a 1.0 release.</p>Ray Vernagushttp://www.blogger.com/profile/12678750838556666846noreply@blogger.com6tag:blogger.com,1999:blog-4585464309698708237.post-55027121420614144732008-09-04T09:05:00.003-04:002008-09-04T09:23:39.028-04:00FsUnit 0.6.0I've just wrapped up a 0.6.0 release of the <a href="http://code.google.com/p/fsunit/">FsUnit</a> specification framework for F#! I'm really starting to appreciate the benefits of writing specifications or tests in a functional language. I hope that this project convinces others in the same way.<br /><br />The F# 1.9.6.0 release is a very important release. F# developers get much deeper support in Visual Studio, for one, and this led a complete overhaul of the tests behind FsUnit. I prefer to do test-driven development when I can, thus a rewrite of the tests meant a rewrite of the framework itself. Everything ended up pretty much the same as it was in the previous release (0.5.0) with a couple of minor changes.<br /><br />The first important change was better messages with failures and errors. The previous release didn't always provide informative messages. With this release, you should always receive enough information to identify the problem.<br /><br />The second important change involves better support for exceptions that may occur when running your specs. Exceptions should not prevent any other specification from running and should one occur, you should get a full stack trace along with the exception message.<br /><br />Finally, there was a slight change to the <code>spec</code> function. Use of <code>spec</code> still evaluates your specification, but it no longer adds it to the internal mutable results collection. I wanted to leave mutable state out of the framework wherever possible, thus, <code>spec</code> now returns a <code>string * Result</code> pair and programmers can choose to use or not to use state in their specifications. If you're lazy like me, you can use the <code>specs</code> function to have FsUnit track your results for you.<br /><br />See the <a href="http://code.google.com/p/fsunit/">project home page</a>, the <a href="http://code.google.com/p/fsunit/w/list">project wiki</a>, or the included <a href="http://code.google.com/p/fsunit/source/browse/#svn/trunk/Examples">examples</a> for more information about the project. Please check it out and let me know how I can make it better!Ray Vernagushttp://www.blogger.com/profile/12678750838556666846noreply@blogger.com0