Unit testing IO in Haskell

Unit testing IO in Haskell(blog.pusher.com)

69 points by fractalsea 10 years ago | 10 comments

gamegoblin 10 years ago |

This is a good post in that it illustrates how it's possible to write useful Haskell that interacts with the real world without weaving IO through the entire codebase (as many beginners end up doing).

I still find myself preferring to use a dependency injection style when writing Haskell. The code ends up looking similar, and more flexible, in my opinion (you can inject different dependencies based on runtime values).

Here is an example using the method described in the article vs. dependency injection to print out the current time.

Article:

    class MonadTime m where
        getTime :: m Integer

    class MonadPrint m a where
        doPrint :: a -> m ()

    instance MonadTime IO where
        getTime = do
            TOD s _ <- getClockTime
            return s

    instance Show a => MonadPrint IO a where
        doPrint = print

    printTime :: (Monad m, MonadPrint m Integer, MonadTime m) => m ()
    printTime = getTime >>= doPrint

    main :: IO ()
    main = printTime

Dependency injected:

    data MonadPrint m a = MonadPrint { doPrint :: a -> m () }

    data MonadTime m = MonadTime { getTime :: m Integer }

    ioMonadTime :: IO Integer
    ioMonadTime = do
        TOD s _ <- getClockTime
        return s

    printTime :: Monad m => MonadPrint m Integer -> MonadTime m -> m ()
    printTime MonadPrint{..} MonadTime{..} = getTime >>= doPrint

    main :: IO ()
    main = printTime (MonadPrint print) (MonadTime ioMonadTime)

Good read on the subject of being careful with overusing typeclasses:

http://www.haskellforall.com/2012/05/scrap-your-type-classes...

platz 10 years ago | |

Of course typeclasses can be viewed as dependency injection as well. It its just that with typeclasses the injection is implicit rather than explicit. But mechanically they are identical

fractalsea 10 years ago | | |

This is what I thought when I first saw the parent comment. It looks like an interesting alternative approach, but from the example I am not clear on why it is more flexible than the version using typeclasses.

I reckon I will need to re-implement my mocks using the technique you describe to really understand the motivation.

gamegoblin 10 years ago | | |

The main difference is that typeclasses are injected at compile time rather than run time. By being explicit, I can inject different behavior based on runtime values.

LukeHoersten 10 years ago |

Pusher is doing some awesome stuff with Haskell! They run a lot of the bitcoin exchange web socket APIs on their infrastructure. I'm sure they have other users too. Cool stuff.

bartq 10 years ago |

finally someone did haskell examples in decent modern blog UI instead of old fashioned dark depressing terminal-like colors ;)

TazeTSchnitzel 10 years ago | |

Code can be beautiful, shame so many people consider xterm to be the height of beauty.

class MonadTime m where getTime :: m Integer class MonadPrint m a where doPrint :: a -> m () instance MonadTime IO where getTime = do TOD s _ <- getClockTime return s instance Show a => MonadPrint IO a where doPrint = print printTime :: (Monad m, MonadPrint m Integer, MonadTime m) => m () printTime = getTime >>= doPrint main :: IO () main = printTime

data MonadPrint m a = MonadPrint { doPrint :: a -> m () } data MonadTime m = MonadTime { getTime :: m Integer } ioMonadTime :: IO Integer ioMonadTime = do TOD s _ <- getClockTime return s printTime :: Monad m => MonadPrint m Integer -> MonadTime m -> m () printTime MonadPrint{..} MonadTime{..} = getTime >>= doPrint main :: IO () main = printTime (MonadPrint print) (MonadTime ioMonadTime)

main = do n <- findOptimalSearchSplitPoint let sortedArraySearch x xs = if sortedArraySize xs <= n then linearSearch x xs else binarySearch x xs let container = Container sortedArraySize sortedArraySearch