Matthew Podwysocki's Blog

In the last installment in this series, we talked about separating the side effecting code from the pure functions.  I gave examples in both Haskell and F# to accomplish this goal, although with Haskell it’s more intuitive due to encapsulating the side effects within the IO monad.  This time, let’s cover how we can abstract the monadic code through the use of type classes.  Using the book, Real World Haskell, has opened up a lot of possibilities in this area.

I know if I were to do a retrospective, it should have been last week, but now is as good a time as any.  2008 was a busy year for myself that I managed to challenge myself and push myself in many different ways.  From joining CodeBetter to speaking at conferences, there has been a lot of things going on.  I’ll focus on three areas, the personal, local and more global levels.

In the last installment in this series, we talked about code coverage, what they are, and how you should use them.  I gave examples in both Haskell and F# to accomplish this goal.  One thing we've touched briefly in this conversation is around refactoring and cleaning up our code, and it’s about time we come back to that subject.

In our previous installment, we talked about bringing together the traditional xUnit tests and QuickCheck property-based tests together in a single cohesive step.  For this installment, let's talk about test coverage.

In the previous post, we talked about using QuickCheck as opposed to traditional xUnit framework testing.  This covered some of the arguments for using property-based testing for our pure algorithms and relegating the xUnit framework tests for the rest.  The question then arises, how do we tie it all together?

In the previous post, we talked about some of the basics of functional programming unit testing.  That post mostly focused around HUnit, which is a traditional xUnit testing framework.  This time, let's focus on type-based property testing, which is to create specs which assert logical properties about a function, and then to generate data to test in an attempt to falsify these assertions, through the use of a tool called QuickCheck.

As you noticed from my last post regarding functional programming and unit testing, there is a bit to be discussed.  Important to any programming language is not only the language, but the frameworks and tooling around it, such is the case with functional languages.  Let's focus on the tooling around testing with functional languages.