Is it a test smell to mix in real implementation and mocks?

To be nitpicking, a unit test is an automated test that tests a unit in isolation. If you combine two or more units, it's not a unit test any more, it's an integration test.

However, depending on the type of units you integrate, having lots of that type of integration tests may be quite okay.

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

In any case you can view the actual implementation as an extreme end of the Test Double Continuum, so 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, just keep in mind that you are no longer testing the unit in isolation, so you do introduce a coupling between the units that makes it more difficult to vary each independently.

To conclude, I still consider it a smell because it should always be an occasion to stop and think. However, a smell indicates no more than that, and sometimes, once you've thought it over, you can decide to move along.

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

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

This is an integration test (combining 2 or more modules) and not a unittest (test one module in isolation)

My answer is No: I think it is ok to have mocks in integration test.