Is the test smell mixed in real implementation and mocks?

I have a consumer class responsible for consuming a string and deciding what to do with it. It can either analyze or insert analysis data into a database or notify the administrator.

Below is my implementation.

public void Consume(string email) { if(_emailValidator.IsLocate(email)) { var parsedLocate = _parser.Parse(email); // Insert locate in database } else if(_emailValidator.IsGoodNightCall(email)) { // Notify email notifying them that a locate email requires attention. _notifier.Notify(); } } 

Below is my unit test.

 // Arrange var validator = new EmailValidator(); var parser = new Mock<IParser>(); var notifier = new Mock<INotifier>(); var consumer = new LocateConsumer(validator, parser.Object, notifier.Object); var email = EmailLiterals.Locate; // Act consumer.Consume(email); // Assert parser.Verify(x => x.Parse(email), Times.Once()); 

Is this the smell of code for mixing mocks and real implementation in unit tests? Also, as always, you need to check if the abc() method always works? It doesn't seem right that after adding a new unit test every time I add a function inside my if block. It seems that if I continue adding to my Consume method, I create a trap.

Thanks.

+7
source share
3 answers

To be nitpicking, the unit test is an automatic test that tests a single unit . If you combine two or more units, this is not a unit test, this is an integration test.

However, depending on the type of units you are integrating, having a large number of similar integration tests can be quite normal.

Krzysztof Kozmic recently wrote a blog post about this, where he describes how Windsor Castle has very few unit tests , but many integration tests. AutoFixture also has a large share of these types of integration tests. I think the most important point is that, as a rule, integration should not cross the boundaries of libraries .

In any case, you can view the actual implementation as the extreme end of the Test Double Continuum , just as there are scenarios where it makes sense to use Stubs, Mocks, Spies or Fakes, there are also scenarios where the actual implementation may make sense .

However, keep in mind that you no longer test the unit in isolation , so you introduce a relationship between units that make it difficult to change each of them independently .

In conclusion, I still consider it a smell, because there should always be a reason to stop and think. However, the smell indicates nothing more, and sometimes, as soon as you think it over, you may decide to move forward.

+8
source

I would say strong yes. Unit testing should be free of dependencies between components.

+3
source
 > Is it a test smell to mix in real implementation and mocks? 

This is an integration test. (combining 2 or more modules), not unittest (one test module is isolated)

My answer is no . I think it’s normal to have mocks in the integration test.

+3
source

All Articles