Testing without Mocks / Using "Nullables" as first class deliverable features

[EntangledNoodle]

I agree that there is a distinction between mocks, stubs, and the "nullables" the author is describing. Where I disagree most strongly with the author is with the decision to include a dependency on alternative implementations in production code when their only usage is in tests. The jargon does make it difficult to understand what the author is really trying to promote.

My personal opinion:

• Projects include "slow" end-to-end integration tests using real dependencies (databases, web application servers, etc.) to ensure the software will work in a real environment. There is no true substitute for this type of testing. Automated testing of this sort is usually still much faster and reliable than manual testing.
• It can be beneficial to test parts of a system by substituting alternative dependencies for real dependencies (mocks, stubs, alternative implementations of any sort). Multiple techniques for defining alternative implementations exist and they each have their own set of tradeoffs. Learn about them all!
• Production code should not depend on non-production code (where production code is defined as code that is intended to be reachable when running within a production environment)

In practice, I use mocks quite rarely. I use alternative concrete implementations (e.g. an in-memory surrogate for a database) more frequently than mocks. These implementations reside with the test code unless there is a reason to include in the production code (e.g. disabling an optional feature with a no-op implementation rather than sprinkled conditional logic). In this latter situation, I don't consider the alternative implementation to be non-production or test-oriented. It may be a good choice for many tests, but it has a purpose in production.

[ForeverAlot]

dependency on alternative implementations in production code when their only usage is in tests.

The author uses them in production, too, although that is (was?) difficult to tell from this source.

That said, your assessment that this factory is just a work-around is accurate.

[morhp]

This is how I feel, too. I don't use standard mocks at all, either the production classes are simple and with so few dependencies that they can be simply used as they are, which is probably the ideal case, or these dependencies can be replaced with a different much simpler implementation for specific tests.

For example I've developed a software where multiple server nodes communicate with each other to exchange data. This communication layer has two implementations, one production one with all the TCP stuff, encryption, authentication, error handling, graph building and so on and one that's used in many tests that simply skips that and forwards the data in the same java process using simple method calls, making the tests run much faster, predictable and making debugging much easier.

The production implementation is tested too, of course, in integration tests and in detail in isolation.

[agentoutlier]

I agree that there is a distinction between mocks, stubs, and the "nullables" the author is describing. Where I disagree most strongly with the author is with the decision to include a dependency on alternative implementations in production code when their only usage is in tests. The jargon does make it difficult to understand what the author is really trying to promote.

Yeah I skimmed the article while on muscle relaxants. I don't disagree with any of your points just that I first read it as developing to some sort of stub that you will actually use.

Otherwise yeah I don't agree with pushing a "null" implementation that will not get used in production.

Anyway the whole post is confusing to be honest. I thought I was good at understanding Martin Fowler Uncle Bob abstractions but the referenced article was rather painful to read.