Because of a recent question on HubFS, I made my future plans for FsCheck public. I'm re-iterating them here:
- smaller bug fixes, some cleaning (mostly done)
- adding FsCheck.fsi module declaration & comments
- Feature: derive generators from types of arguments (mostly done)
- Feature: ability to group properties in classes, and check the class with one command (mostly done)
- Investigate using FsCheck with unit testing frameworks like MbUnit & co, or generally how to use it in practice (currently active)
- putting the project on codeplex + clarifying license . I'm checking compatibility with the QuickCheck license, but I'm aiming for a permissive license, like the new BSD license.
I intend to finalize this before the end of the year.
Finally, you can help by answering the following question. How are you using FsCheck? Do you have a separate console app that you run that contains your properties, or do you use F# interactive with the properties inline, or something else?
I currently check properties as a console app. How I'd really like to check properties is making them Visual Studio unit tests, and having that invoke them.
ReplyDeleteAll those things look good! What would really be nice is a standard web page for FSCheck - currently its just a pile of blog entries but a nice URL to get the latest version from would make it easier. A source code repo would also be nice :-)
As a side note, have you considered making Result.arguments lazy? I found that the any_to_string call in forAll can be a bottleneck on large structures, and its often wasted work unless you are using verbose.
You also do any_to_string twice on a failing example, which makes it harder for long expressions which any_to_string uses intentation and newlines on.
Thanks for the useful tool!
Hi Neil,
ReplyDeleteThanks for the comments.
Yes, a project page would definitely be nice. I'll also centralize the documentation, binary and code there.
With regard to the unit tests: the problem with mstest is that it only recognizes tests in C# and VB.net projects. That's a pretty sad limitation, that I hope microsoft will solve eventually (especially with F#, IronPython and IronRuby and whatnot on the block), but is kind of a show stopper for Visual Studio integration at the moment. That said, I am doing some work on easier integration with your favourite unit test framework (mbunit, xunit, nunint, mstest, whatever).
I'll look at your suggestion concerning lazyness. Should be fairly straightforward. Thanks!
Kurt
The other alternative to using lazy<array<string>> would be to store the arguments as array<obj> then the individual verbose functions could either call any_to_string, or do something more clever if they wanted. You'd also remove the laziness, and retain the performance.
ReplyDeleteI include a script file in my project and run it either in interactive mode or as a batch.
ReplyDeleteAlso I modified the "tests" function to return a bool indicating success or not. That allows my to do an NUnit assert so I can take advantage of this in my unit tests package.
At A6 Systems we are talking about testing this with a live client.
This is great work Kurt - thanks for working this up in F#. I look forward to it being placed in an open version system so I can contribute.