Everyone tell Don't mock what you don't own. They recommend to make a wrapper for 3rd party library instead.
But how do I test this wrapper?
I mean, if I write unit tests for it and will mock those 3rd party interfaces to test my wrapper, nothing will change. If library maintainer will change its API I will face same problem - tests for mocked lib will go fine and software will fail in production environment. What is the advantage for reliability or testability here?
I know there is advantage for code quality because I could exchange this library whenever I want, but it is not subject of this question.
Thanks.
If you want to test the interaction with the 3rd party or with the file system, then what you need is integration testing which means that you test all the parts that have already been unit tested and assert how they work together.
Learning a Language Using Unit Tests For Java, this core library is known as the Java Class Library (JCL).
A typical unit test contains 3 phases: First, it initializes a small piece of an application it wants to test (also known as the system under test, or SUT), then it applies some stimulus to the system under test (usually by calling a method on it), and finally, it observes the resulting behavior.
There is unit testing your abstractions of 3rd party libraries to make sure your code operates as intended and then there is integration testing against 3rd party libraries to make sure that the behavior of those integration are as intended. If those 3rd party libraries have sand boxes that you can safely test against, even better.
If for example your system under test a one that is dependent on a 3rd party library but you want to unit test it without calling the actual library. You provide a Mock implementation of the 3rd party interface either manually or using a mocking framework.
public interface IExteralContract {
List<string> DoSomething(params string[] args);
}
[TestMethod]
public void SUT_Should_Be_True {
//Arrange
IExteralContract mock = new MockExternalContract();
var sut = new MyClass(mock);
//Act
var actual = sut.DoSomethingElse();
//Assert
Assert.IsTrue(actual);
}
In this case the system under test was one of your classes that was dependent on the 3rd party interface.
For your integration test the system under test is the actual 3rd party wrapper to make sure that it behaves as intended.
public class ConcreteExternalWrapper : IExteralContract {
public List<string> DoSomething(params string[] args){
//Actual calling of 3rd party libraries
}
}
[TestMethod]
public void Third_Party_Service_Should_Return_Data {
//Arrange
IExteralContract sut = new ConcreteExternalWrapper ();
int expected = 3;
//Act
var actual = sut.DoSomething("arg1", "arg2", "arg3");
//Assert
Assert.IsNotNull(actual);
Assert.AreEqual(expected, actual.Count);
}
That way if the library maintainer changes its API the behavior would cause the expected behavior to fail.
Hope this satisfies what you were asking about.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With