In the next couple of posts, I’m going to implement a minimal version of QuickCheck from scratch. Follow along and you’ll:
- learn how QuickCheck works
- become better at using it1
- see a bit of Quviq’s QuickCheck in Erlang as well
Here’s a list of posts to follow:
- Write you some QuickCheck: Generating random bytes
- Write you some QuickCheck: Generating random characters
- Write you some QuickCheck: Generating random booleans
- Write you some QuickCheck: Generating random 32-bit signed integers
- Write you some QuickCheck: Generating random 64-bit signed integers
- Write you some QuickCheck: Generating random 32-bit floating-points
- Write you some QuickCheck: Generating random lists
- Write you some QuickCheck: Shrinking numbers
- Write you some QuickCheck: Shrinking bytes, characters, and booleans
- Write you some QuickCheck: Shrinking lists
Write you some QuickCheck: Shrinking strings
- Write you some QuickCheck: Properties
- Write you some QuickCheck: Properties that hold under certain conditions
- Write you some QuickCheck: Properties that are labeled
Write you some QuickCheck: Properties that are labeled conditionally
- Write you some QuickCheck: Putting everything together
- Write you some QuickCheck: Where’s the Arbitrary class?
This is advanced material. Basic knowledge of QuickCheck and property-based testing is assumed. If you’re in the beginning it’s fine! Read this post first by Scott Wlaschin, followed by this Pluralsight course by Mark Seemann, followed by these slides by Pedro Vasconcelos. There’s also this short intro as well. ↩
Using a build server can actually hurt productivity:
- It introduces a single point of failure
- It can yield false-positives
- It can yield false-negatives
- It consumes time and energy to configure it properly
Think about it – you may not need a build server, after all.
It introduces a single point of failure
When things fail on the build server, it looks bad. It doesn’t matter if the build succeeds on the developer machines. – Seriously?
It can yield false-positives
The build might succeed on the build server, while fail on the developer machines. – Now what?
It can yield false-negatives
The build might fail on the build server for a whole lot of (unrelated) reasons to the build itself. Does that mean we’re screwed? – We might not.
It consumes time and energy to configure it properly
It’s one of those days where you end up spending more time getting the build server to work, than working on something else that’s probably more useful.
Bring fun back to work:
- Run the build on a few developer machines.
- Report back whether it succeeds or not, and rely on that.
Get rid of those pesky build servers.
Source code available on GitHub.
In F#, a similar generator for FsCheck can be written as:
Use in F# Interactive
Here’s a way to generate regex-constrained strings with FsCheck in F# Interactive:
Notice how FsCheck yields different results on each run:
matching takes the size of generated test data into account.
Use in FsCheck with xUnit.net
While F# is first-class citizen in Visual Studio, there’s also support for text editors:
- via fsharp/fsharpbinding for Emacs, Vim, and Sublime Text
- via Krzysztof-Cieslak/FSharp.Atom for Atom
Beyond Visual Studio
There are always a couple of steps to be done, and basic knowledge of the target text editor is also assumed.
A flexible, easy way, with Spacemacs
Open a Git Bash command prompt window:
Then, launch Emacs and Spacemacs will automatically load, installing all required packages. After that, Emacs must be restarted.
After opening Emacs, it should show
~/.spacemacs under Recent files. – Click on that file to open it.
Add F# as shown in the following diff-output:
Then hit CTRL+C & CTRL+C, and the Spacemacs layer for F# will install itself.
Essentially there are two things needed:
- GHC – Haskell’s compiler and interactive environment.
- Cabal – Haskell’s build system, which also doubles as a package manager.
- Download GHC for Windows from here.
- Extract GHC contents to a folder and add to PATH
- Download Cabal for Windows from here.
- Extract Cabal executable to a folder, open a command prompt (cmd.exe) and execute:
- Open a MSYS-compatible (e.g. Git Bash) shell and execute:
- cabal-x.y.z.exe install
- Delete cabal-x.y.z.exe (after
cabal-installis completed successfully)
C:\Users\[YOUR USERNAME]\AppData\Roaming\cabal\binto PATH
Did it work out?
Open a command prompt (cmd.exe) window or a Git Bash window and execute
where cabal, which should print the path where cabal executable resides:
In the same command prompt executing
ghci should launch GHCi (Haskell’s interactive environment):
To get the
> character show up in the prompt, add the following to
That’s it – Happy Haskell Programming!
subscribe via RSS