Hacker News Reader

Comment by mx_03 | Hacker News Reader

>This is better. Now the only code that differs between a unit test build and a production build is what clock_factory::get_clock() returns.

So you are effectively testing code that will never see the light in Production. That's called a Mock and some people hate mocks.

I have no problem against it taking for granted the actual lib has its own tests.

View on HN

I thinks mocks are better in C++ than in dynamic languages. In C++ you need to expose a public interface for the customization point so it can be mocked. Mocks therefore test a public interface and not implementation details. Granted, if that "public interface" is not used outside of tests then it's not much different, but I think it adds the correct amount of friction for mocking.

In dynamic languages you can mock anything, even parts that are not designed to be customizable. This indeed has the effect of calcifying implementation details, as mocks don't test a public interface. I think it's harder in this environment to stay disciplined and use mocking in moderation, as the friction to only mock public interfaces is not there.

I definitely saw this in C++ vs Python mocking, mocking tends to be way overused in Python testing.

> That's called a Mock and some people hate mocks.

Don't worry to much about them.

Mocks are perfectly OK.

It is like putting a mechanical device in a jig for a durability test or the exhaust extractors that mechanics use when they run engines inside the workshop.

Mocks are okay, if they are used correctly. Often I see them over constraining code and then you cannot change it. If the code will not change delete the tests at they will never fail.

> If the code will not change delete the tests at they will never fail.

Or, unless they are expensive, just keep them. The code doesn't change so they won't break.

But for the next maintainer they will tell them a lot. One particularly nice thing about some code I maintained recently was that it allowed me to run through different scenarios in my debugger even during my first days in that code base.

Also I don't think I will ever again assume that some code that is in production will never change.

I generally assume that production code will change in the future. Thus if the tests you write today do not guide those changes to not break other existing functionality since they so constrain your implementation that those tests will need to be deleted then the tests are not valuable.

I've seen code where every dependency was mocked and all tests ended up being the implementation calls some function with some arguments. Most of the functions can be called many different ways to get the same answers, but the tests forced a specific number.

It is easy to do mocks wrong.

Here is however an example of how one does it right.

Say you have a system that accepts input, does something with it and stores it to some storage.

You don't want to touch actual storage in the build pipeline.

Then you mock in testing out the storage.

Everything can still be tested:

- the validation of incoming stuff isn't affected at all

- the transformations aren't affected

- the only difference is your tests now read the output back from a memory location instead of from a permanent storage somewhere

Reply on news.ycombinator.com