3 ms·

>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 effecti

by mx_03 3y ago

>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.

eitland 3y ago
> 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.
- bluGill 3y ago
  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.
  - eitland 3y ago
    > 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.
    - bluGill 3y ago
      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.
      - eitland 3y ago
        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
planede 3y ago
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.

by mx_03 3y ago

eitland 3y ago

> 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.

bluGill 3y ago
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.
- eitland 3y ago
  > 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.
  - bluGill 3y ago
    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.
    - eitland 3y ago
      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

planede 3y ago

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.