Replacing IO with pure values
Hello all, in order to nail down my problem state in "Replacing the world in a State Machine with IO", I'd like to answer a much simpler question: If I have function which reads IO and I want to test this function by passing it a series of pure values, how would I do this? I suppose I can do this by splitting my function in two, such that the outer function does IO and the inner is a pure function. Is there any other way?
This Stackoverflow give a lot of hints:
http://stackoverflow.com/questions/7370073/testing-functions-in-haskell-that...
You cannot "Unit" test functions that 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.
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.
On Mon, Nov 24, 2014 at 4:22 PM, martin
Hello all,
in order to nail down my problem state in "Replacing the world in a State Machine with IO", I'd like to answer a much simpler question:
If I have function which reads IO and I want to test this function by passing it a series of pure values, how would I do this? I suppose I can do this by splitting my function in two, such that the outer function does IO and the inner is a pure function. Is there any other way?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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.
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
There's https://hackage.haskell.org/package/IOSpec which provides a pure
implementation of the IO monad. Once you're done testing your code you can
import Test.IOSpec.Surrogate which declares type IOSpec f a = IO a.
Would be a nice use case for ML-style modules btw :)
On Mon Nov 24 2014 at 9:46:29 PM martin
Thanks to all. This helped a lot.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Corentin Dupont -
David Thomas -
martin -
Paul Brauner