Unit test area

Question

Say we have a remote Alpha service, with the GetUser (id, includePurchases) method.
The method has this rule:



- If includePurchases is true, user.Purchases must have a shopping list.
- If not, user. The acquisition must be empty.

Let's say we have a beta version of the site, with UserRepository, which has a GetUser (id, includePurchases) method.
Beta.UserRepository.GetUser () calls Alpha.GetUser () inside.

---

The Alpha team says Beta should have a test that validates this special rule.
I did not agree, because if you have a unit test that calls a service, this is an integration test.

They don’t want the beta test to call Alpha, but instead they need a test that mocks the Alpha.GetUser method to include something like "if (includePurchases) user.Purchases = new List ()".
With this “if”, a test will be written on the spot that approves the user. Purchases are empty or independent of the includePurchases flag.

---

Does that make sense to you?
The testing they want should this be an Alpha unit test problem only?
It seems to me that I am writing a test that tests the assumption of how Alpha works.

Answer 1

That sounds perfectly normal and legal in terms of componentization, and yes, you're right, the Beta unit test, which actually calls, the Alpha service is an integration test.

Remember that if you write unit tests for Beta functionality, you are only responsible for the beta and beta. It is appropriate and prefers Mock to call the Alpha service, because your unit test should assume that these external dependencies work exactly as announced.

Mocking the functionality in the beta, you guarantee the repeatability and consistency of the unit test, which tests the functionality of ONLY Beta. Thus, if the beta process crashes in the environment, and your unit test passes, then there should be a problem with the Alpha web service, and then another team is responsible for fixing and fixing this error.