I have a class that uses 3rd party FTP library http://ftps.codeplex.com/ and I would like to mock it so that I can unit test just that class and not the FTP library. I have done it but it feels messy to me. In detail, the class uses these methods of AlexPilotti.FTPS.Client.FTPSClient class:
public string Connect(string hostname, ESSLSupportMode sslSupportMode)
public ulong PutFile(
string localFileName, string remoteFileName,
FileTransferCallback transferCallback)
Delegate AlexPilotti.FTPS.Client.FileTransferCallback looks like this:
public delegate void FileTransferCallback(
FTPSClient sender, ETransferActions action,
string localObjectName, string remoteObjectName,
ulong fileTransmittedBytes, ulong? fileTransferSize, ref bool cancel);
You can see a problem because PutFile takes the delegate from FTP library and that delegate takes two different types from the library as well. I decided to use generics to decouple from these types.
To be able to create a mock object, I created an interface and then a derived class which is a wrapper of the FTP library functionality.
// Interface so that dependency injection can be used.
public delegate void FileTransferCallback<T1, T2>(T1 sender, T2 action,
string localObjectName, string remoteObjectName,
ulong fileTransmittedBytes, ulong? fileTransferSize,
ref bool cancel);
public interface IFTPClient<T1, T2> : IDisposable
{
string Connect(string hostname, System.Net.NetworkCredential credential);
ulong PutFile(
string localFileName, string remoteFileName,
FileTransferCallback<T1, T2> transferCallback);
}
// Derived class, the wrapper
using FTPSClient = FTPS.Client.FTPSClient;
using ETransferActions = FTPS.Client.ETransferActions;
public class FTPClient : IFTPClient<FTPSClient, ETransferActions>
{
public FTPClient()
{
client = new AlexPilotti.FTPS.Client.FTPSClient();
}
public ulong PutFile(
string localFileName, string remoteFileName,
FileTransferCallback<FTPSClient, ETransferActions> transferCallback)
{
callback = transferCallback;
return client.PutFile(localFileName, remoteFileName, TransferCallback);
}
public void Dispose()
{
client.Dispose();
}
public string Connect(
string hostname, System.Net.NetworkCredential credential)
{
return client.Connect(hostname, credential,
FTPS.Client.ESSLSupportMode.ClearText);
}
void TransferCallback(
FTPS.Client.FTPSClient sender, FTPS.Client.ETransferActions action,
string localObjectName, string remoteObjectName,
ulong fileTransmittedBytes, ulong? fileTransferSize,
ref bool cancel)
{
callback.Invoke(sender, action, localObjectName, remoteObjectName,
fileTransmittedBytes, fileTransferSize, ref cancel);
}
private AlexPilotti.FTPS.Client.FTPSClient client;
private FileTransferCallback<FTPSClient, ETransferActions> callback;
}
Here goes a class that uses this interface and which I unit test. I stripped it down a bit so only the Connect method is used but I hope it still illustrates my problem.
public class FTPServerConnection<T1, T2>
{
public void Init(
IFTPClient<T1, T2> client, string serverName,
string userName, string passwd)
{
IsConnected = false;
ServerName = serverName;
UserName = userName;
Passwd = passwd;
ftpClient = client;
Connect();
}
public void Connect()
{
ftpClient.Connect(
ServerName,
new System.Net.NetworkCredential(UserName, Passwd));
}
public string ServerName { protected set; get; }
public string UserName { protected set; get; }
public string Passwd { protected set; get; }
public bool IsConnected { protected set; get; }
private IFTPClient<T1, T2> ftpClient;
}
And finally the unit test:
[TestMethod()]
public void FTPServerConnectionConstructorTest()
{
var ftpClient = new Mock<IFTPClient<object, object>>();
var ftpServer = new FTPServerConnection<object, object>();
ftpServer.Init(ftpClient.Object, "1.2.3.4", "user", "passwd");
Assert.AreEqual("1.2.3.4", ftpServer.ServerName);
Assert.AreEqual("user", ftpServer.UserName);
Assert.AreEqual("passwd", ftpServer.Passwd);
}
What is the usual approach in situations like this one? My approach seems to be messy and I am wondering if there is easier way of doing it. Thanks.
I think this only feels messy because you’ve had that third party delegate to cope with, but it looks like a pretty standard abstraction / mocking approach to me.
My only comment would be that the structure of
FTPServerConnectionlooks a bit non-standard; the way it’s written you have to instantiate one in an invalid state (i.e. one with no client details) then callInit(), which itself callsConnect()(which from the look of your test is never called by a client of the server class). It would be more normal I’d say to have the arguments toInit()supplied in theFTPServerConnectionconstructor, then remove theInit()method altogether and have the client do this:…but again, regarding the way you’ve abstracted the FTP library, I think that’s a decent way of doing it 🙂