Unit-testing – How do functional languages handle a mocking situation when using Interface based design

%ffunctional programmingmockingunit testing

Typically in C# I use dependency injection to help with mocking;

public void UserService
{
  public UserService(IUserQuery userQuery, IUserCommunicator userCommunicator, IUserValidator userValidator)
  {
    UserQuery = userQuery;
    UserValidator = userValidator;
    UserCommunicator = userCommunicator;
  }

  ...

  public UserResponseModel UpdateAUserName(int userId, string userName)
  {
     var result = UserValidator.ValidateUserName(userName)
     if(result.Success)
     {
       var user = UserQuery.GetUserById(userId);
       if(user == null)
       {
          throw new ArgumentException();
          user.UserName = userName;
          UserCommunicator.UpdateUser(user);
       }
     }
     ...
  }

  ...
}

public class WhenGettingAUser
{
  public void AndTheUserDoesNotExistThrowAnException()
  {
     var userQuery = Substitute.For<IUserQuery>();
     userQuery.GetUserById(Arg.Any<int>).Returns(null);
     var userService = new UserService(userQuery);
     AssertionExtensions.ShouldThrow<ArgumentException>(() => userService.GetUserById(-121));
  }
}

Now in something like F#: if I don't go down the hybrid path, how would I test workflow situations like above that normally would touch the persistence layer without using Interfaces/Mocks?

I realize that every step above would be tested on its own and would be kept as atomic as possible. Problem is that at some point they all have to be called in line, and I'll want to make sure everything is called correctly.

Best Answer

Typically, I would go about this by writing a function that returns a representation of the action that I want to perform on the external resource rather than performing the operation itself. This way the logic and the act of IO are decoupled and testing is much easier.

Related Topic