Say we have a remote service Alpha, with a method GetUser(id, includePurchases).
The method has this rule:
– If includePurchases is true, user.Purchases should have a list of Purchases.
– If not, user.Purchases should be blank.
Say we have a website Beta, with a UserRepository that has a method GetUser(id, includePurchases).
Beta.UserRepository.GetUser() calls Alpha.GetUser() internally.
The team responsible for Alpha says Beta should have a test that checks for that special rule.
I disagreed, because if you have a unit test that calls the service, that’s an integration test.
They don’t want the Beta test to call Alpha, but instead want a test that mocks the Alpha.GetUser method to include something like “if (includePurchases) user.Purchases = new List()”.
With that “if” in place, a test would be written that asserts user.Purchases is blank or not depending on the includePurchases flag.
Does this make sense to you?
The test they want, should that not be a concern solely for the Alpha unit tests?
To me, it seems like I’m writing a test that checks for an assumption about the way Alpha works.
This sounds perfectly normal and legitimate from a componentization standpoint, and yes you are right, a Beta unit test that actuallys calls the Alpha service is an Integration Test.
Remember that if you are writing unit tests for the functionality of Beta then you are responsible for Beta and Beta alone. It is appropriate and preferred to Mock the Alpha service call because your unit test should assume that these external dependencies work exactly as advertised.
By mocking the functionality in Beta, you guarantee a repeatable and consistent unit test that verifies the functionality of ONLY Beta. In this way if the Beta process fails in the environment, and your unit test passes, then there must be a problem with the Alpha web service and then it is the other teams responsibility to address and fix this bug.