Depending on your scope, one thing you could do is replace the things
that operate against IO with functions that operate against some other
interface, and then provide an IO-based implementation and a pure
implementation of that interface.
That works best where the IO activity is fairly simple; of course,
when that's true you can often find ways to factor it out and just get
yourself a pure function to test anyway. It works worst when you're
calling out into complicated libraries that live in IO. There may be
a sweet spot between these two where it would be a good fit.
On Mon, Nov 24, 2014 at 8:26 AM, Corentin Dupont
This Stackoverflow give a lot of hints: http://stackoverflow.com/questions/7370073/testing-functions-in-haskell-that...
You cannot "Unit" test functions that performs IO, because by definition a unit test is about testing an isolated piece of code that give the same result for the same input, i.e. pure. In my programs I separate the non-IO parts for the IO parts, so that I can test the non-IO parts. The IO parts are mainly the GUI parts of my apps, which I test manually.
Now it should be possible to trick the IO monad by supplying always the same user input to your function, but I don't know how to do that.t performs, because by definition a unit test is about testing an isolated piece of code that give the same result for the same input, i.e. pure.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe