Should I mock IO or not? - unit-testing

Question

Say I have a simple file based database Monad. I would define it as shown below.
newtype MyDbFileBased a = MyDbFileBased {
unMyDbDbFileBased :: ExceptT MyDbFileBasedError (ReaderT MyDbFileBasedEnv IO) a
} deriving (
Functor
, Applicative
, Monad
, MonadError MyDbFileBasedError
, MonadReader MyDbFileBasedEnv
, MonadIO
)
I have read that the above pattern (will post a link to the blog when I find it) is not recommended and that I should replace IO with a generic Monad like so.
import qualified Data.ByteString as B
newtype MyDbFileBased m a = MyDbFileBased {
unMyDbFileBased :: ExceptT MyDbFileBasedError (ReaderT MyDbFileBasedEnv m) a
} deriving (
Functor
, Applicative
, Monad
, MonadError MyDbFileBasedError
, MonadReader MyDbFileBasedEnv
)
class Monad m => MonadFileBasedIO m where
readBytes :: FilePath -> m B.ByteString
writeBytes :: FilePath -> B.ByteString -> m ()
...
instance MonadFileBasedIO IO where
readBytes = B.readFile
writeBytes = B.writeFile
This will supposedly make unit testing easier. The advise is to mock IO in testing with something like as follows.
data MockFS = EmptyDir
| SingleFile FilePath String
deriving (Show)
newtype MockFileBasedIO a = MockFileBasedIO {
unMockFileBasedIO :: State MockFS a
} deriving (
Functor
, Applicative
, Monad
, MonadState MockFS
)
instance MonadFileBasedIO MockFileBasedIO where
readBytes pathReq = do
dir <- get
case dir of
EmptyDir -> fail "file not found"
SingleFile path contents -> if pathReq == path
then pure (BU.fromString contents)
else fail "file not found"
writeBytes path = put . SingleFile path . BU.toString
All this looks good to me until now. But then I want to add things like catch and liftIO to functions within MyDbFileBased type. I thought of adding catchMonadFileBasedIO and liftMonadFileBasedIO functions to MonadFileBasedIO typeclass and set catchMonadFileBasedIO = catch and liftMonadFileBasedIO = liftIO for IO monad. But then it brings in dependency on MonadIO and Exception typeclasses and the compiler tells me to add these typeclasses to function signatures of catchMonadFileBasedIO and liftMonadFileBasedIO. Also I would need to derive MonadIO from MyDbFileBased m. Then what's the point of replacing IO with a generic Monad in the first place?
I don't understand if I should be mocking IO in cases such as these or not. How do I use liftIO and catch if we mock it? Should I not catch exceptions in this module and cascade them to application level?

Answer 1

Then what's the point of replacing IO with a generic Monad in the first place?
As a general piece of advice, that might enable you to replace IO with something pure when testing.
Unit tests ought to be deterministic, which is one of the two characteristics of pure functions. Thus, being able to frame any problem in terms of pure functions makes it intrinsically testable.
In order to make a set of interactions pure and testable, you can, for example, replace m with State, and run your unit tests in the State monad. Here's an example. Here's an example with Writer.
In general, I'd recommend avoiding 'mocking' if possible. In object-oriented programming, this may be a necessary evil to enable testing, but it typically leads to hard-to-maintain code. In functional programming, unit testing is much easier, but it typically requires you to design the modules of your application in a functional style.
Introducing a type class as something equivalent to an object-oriented interface or base class is unlikely to lead to a a functional design. This will pull you towards a programming model where the (impure) interactions are at the centre of your application architecture. That's exactly what makes object-oriented programming so difficult.
In functional programming, you're much better off pushing the impure interactions to the edge of the system. This'll enable you to unit test your (pure) domain logic, while the IO remains concrete.