Showing posts with label xunit. Show all posts
Showing posts with label xunit. Show all posts

19 June 2013

FsCheck 0.9 Released and moved to GitHub

FsCheck has a new home on GitHub. I wanted to move to GitHub for a while, because it’s where all the cool kids hang out, and @carstkoenig gave me the necessary push. I hope the barrier for contributions is now low enough to get you to chip in if you feel like it, and simplifies the life of existing contributors. (Not that I’m complaining. You’ve been great.)

As for the long overdue release - a significant portion of contributions didn’t come from me.

Here are the highlights of the change log:

  • New generators for KeyValuePair, IList, ICollection, Action, Func, decimal (@mausch) and sbyte (@jackfoxy).
  • Finally compiled against FSharp.Core 4.3 (no more binding redirect. Yay.)
  • FsCheck.Xunit now allows you to replay a certain test by pasting in the seed from the output in the PropertyAttribute’s Replay property. This should help with debugging:
    [<Property(Replay="54321,67584")>]
  • FsCheck.Xunit also allows defining ArbitraryAttribute on an enclosing module or type now – the given Arbitrary instances are then available for all properties in the type or module. But you can still override them if you define one on a specific property. 
        [<Arbitrary(typeof<TestArbitrary2>)>]
        module ModuleWithArbitrary =
    
            [<Property>]
            let ``should use Arb instances from enclosing module``(underTest:float) =
                underTest <= 0.0
    
            [<Property( Arbitrary=[| typeof<TestArbitrary1> |] )>]
            let ``should use Arb instance on method preferentially``(underTest:float) =
                underTest >= 0.0

Hope you enjoy.

Technorati Tags: ,

26 August 2012

FsCheck 0.8.3 and FsCheck.Xunit 0.3

I’ve just uploaded new NuGet packages for FsCheck and FsCheck.Xunit.

The changes are minor:

  • FsCheck.Xunit now works with instance methods. NCrunch, for example, reportedly only works with instance methods, so this means you can now use NCrunch for running FsCheck properties.
  • Both NuGet packages now call Add-BindingRedirect on install. This will generate an app.config file in your test project if necessary, to spell out to the .NET loader that tests compiled with F#3.0 and so in all likelihood using FSharp.Core 4.3 should indeed use 4.3 instead of the older 4.0, which FsCheck is compiled with.
  • Added symbols on symbolsource.org.

Note that running “Add-BindingRedirect <project name>” in the NuGet package manager console should resolve any problems you may have running FsCheck in VS2012. Also, since xunit is strongly signed, there are similar problems with FsCheck.Xunit – Add-BindingRedirect solves that one too.

If you’re not into NuGet, add the following lines to your app.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>
Technorati Tags: ,,
Share this post : MSDN! Technet! Del.icio.us! Digg! Dotnetkicks! Reddit! Technorati!

26 June 2012

FsCheck 0.8.1: The ecosystem release

Yesterday I’ve released a new version of FsCheck. There are some minor changes, additions and bug fixes to FsCheck itself. The most important part of this release is that FsCheck is now integrated with Xunit through the new FsCheck.Xunit assembly.

For the impatient: NuGet packages for FsCheck and FsCheck.Xunit

Here goes a more detailed overview.

Generators are now applicative. Or, without the general abstract nonsense: say you’ve got three generators

let ga,gb,gc :Gen<_> * Gen<_> * Gen<_>

And you have a function of three arguments that you’d like to map over those.

let f = fun a b c ->

No problem, you can use Gen.map3 – right? But how many instances of map do you need? FsCheck currently defines 6. But now that Gen is applicative, we can write:

let result = f <!> ga <*> gb <*> gc

Hey, doesn’t that almost read like function application? That’s the idea. The weird operators in between just make sure everything is applied properly. Besides being a bit nicer to use sometimes, you can also keep chaining this indefinitely, up to any arity.

And hey, if you still prefer map, FsCheck still has those.

New generators. Mauricio Scheffer contributed int64 and TimeSpan generators. I’ve also added an int16 generator, and DontSize wrappers for all of those – the default generators for int16, 32 and 64 will generate integers smaller than the test size, which is increased by FsCheck as the test progresses. The DontSize variants ignore the size and always pick from the whole range for the type.

Xunit integration. Xunit is a very nice framework – very simple to use and extend. FsCheck integrates with Xunit by adding a PropertyAtttribute. To use it, just use Property instead of Fact, and you can now give your test arguments. These are randomly generated by FsCheck. You can also use all of the normal property combinators in the Prop namespace. A couple of examples:

[<Property>]
let ``abs(v) % k equals abs(v % k)`` v (NonZeroInt k) = 
    (abs v) % k = abs(v % k)
[<Property>]
let ``divMod should satisfy definition`` (x:int) (y:int) = 
    y <> 0 ==> lazy (let (d,m) = divMod x y in d*y + m = x)

Note that Property test methods, as opposed to Fact, don’t need to return unit – they can return anything that’s testable with FsCheck, including bool. But since a test fails in FsCheck when it throws an exception, you can still use the Assert class if you like. You can also use FsUnit or Unquote or whatever to write your assertions. FsCheck does not care – it does the hard work of generating random values and shrinking them if the test fails and generally tries to get out of your way for the rest.

You can also set various configuration parameters using the Property attribute, which then apply to that method only. Most of these are trivial (e.g. the number of tests), but an interesting one is that you can override the random generation for certain types on one test method only:

type TestArbitrary1 =
    static member PositiveDouble() =
        Arb.Default.Float()
        |> Arb.mapFilter abs (fun t -> t >= 0.0)

[<Property( Arbitrary=[| typeof<TestArbitrary1> |] )>]
let ``should register Arbitrary instances from Config in last to first order``(underTest:float) =
    underTest >= 0.0

Here the generator for float is overridden to generate only positive floats.

Finally, a special thanks to @mausch for contributing, integrating FsCheck with Fuchu, and giving me a gentle nudge to get this release out the door at last!

Technorati Tags: ,,
Share this post : MSDN! Technet! Del.icio.us! Digg! Dotnetkicks! Reddit! Technorati!

16 December 2010

F#, xUnit theories and InlineData

How do you know you haven’t blogged much lately? When you want to write a blog post and you forgot the name of the thing you’re actually writing it with. “Wait, it’s called Window Live something something…what did that icon look like again?”. Also, Windows Live Writer now has a ribbon! Good stuff.

Anyway, just a short heads up to save people some time: in the xUnit extensions, there is a Theory attribute which in combination with the InlineData attribute lets you specify a parameterized xUnit test. The InlineData attribute lets you specify the values the test should run with (you can’t test everything randomly with FsCheck, you know). That and other xUnit extension goodies are explained here.

My point is – this attribute does not work in F# (or managed C++), because the AttributeUsage attribute on the InlineData attribute is defined on its parent class, DataAttribute. It is correctly defined as Inherited = true; but only the C# compiler seems to honour this. More detailed explanation in this stackoverflow post. If  you care about this, please vote for the bug on the xUnit site!

Luckily, the workaround is not too bad – just use the PropertyData attribute instead:

let symbolTestData = 
    [ "an1 rest",           "an1"
      "?test bla",          "?test"
      "?+_est bla",         "?+_est"
      "+_123 bla",          "?+_123"
      "+._1.2.3 bla",       "+._1.2.3"
      "+_q1r-2g3! bla",     "+_q1r-2g3!"
      "abc.def.feg/q bla",  "abc.def.feg/q"
      "ab/cd? bla",         "ab/cd?"
    ]
    |> Seq.map (fun (a,b) -> [|a; b|])

[<Theory>]
[<PropertyData("symbolTestData")>]
let ``should parse symbol``(toParse:string, result:string) =
    Assert.Equal(result, run symbol result)

Note that xUnit actually expects a sequence of arrays, but I think the list of tuples looks better, at the small cost of an extra conversion step.

Technorati Tags: ,,
Share this post :