5 ms·

Not particularly convincing. Mocks work well because you can quickly define them in a given unit test and forget about it. I can see fakes being useful in cert

Not particularly convincing. Mocks work well because you can quickly define them in a given unit test and forget about it. I can see fakes being useful in certain cases, but only just in certain cases. Could be my inexperience with C#, but it didn't do justice describing the point in code samples.

ddek 6y ago
I question a lot of advice like this, and agree with you. I’d generally far rather use NSubstitute than have to write fake classes, but I can see the utility in some cases. My honest response is this: Writing tests should be quick and painless. Maintaining fakes is more painful than maintaining substitutes. Substitutes let me interrogate side effects in great detail. I’m not concerned will performance in unit tests. Ergo, substitutes are quicker and less painful, so IMO that’s a win. But for real though, why should anyone care about someone else’s test architecture, of all things. As long as you neither under- or over-testing, why on earth does it matter?
- doubletgl 6y ago
  > why should anyone care about someone else’s test architecture, of all things. As long as you neither under- or over-testing, why on earth does it matter? If you have to maintain tests written by other devs you might start to care. Devs apply different patterns to writing tests and show different amounts of discipline doing so. Some produce lots of duplication ("it doesn't matter, it's just a unit test"), others prefer a complete setup and tear-down before and after every little assertion. I've seen things..
  - andix 6y ago
    I've seen unit tests that test around bugs. Once you fix the bug, a lot of tests fail. Then you discover there is no easy fix for the test. Either delete them all or replace them with new ones.
- deleted 6y ago
  [deleted]
jrockway 6y ago
I tried to distill down the basics a few years ago in a 1 page article: https://testing.googleblog.com/2013/06/testing-on-toilet-fake-your-way-to.html https://testing.googleblog.com/2013/06/testing-on-toilet-fak... The example is a little contrived, but the whole article fits on one sheet of paper and does yield a better test than mocks would. Testing against the real system is always better than testing against a fake. That should be your first preference, and if you can modify the system to make testing against it easier, that's even better. Sometimes you can't, and if your interaction is complicated and the parts that you care about are simple, a fake can get you good confidence that your part works. Mocks just feel like writing the code again -- in your code, you write "call a function with an argument, then call another function with an argument" and in the tests you write "pass if a function is called with an argument, and again with an argument". It can be the right thing at the right time, but it's usually writing a test to make some automated linter shut up. And that's a complete waste of time.
- rocqua 6y ago
  > if you can modify the system to make testing against it easier, that's even better. What do you mean here? Changing your testing system, or changing the real system?
  - jrockway 6y ago
    Changing the real system to add the hooks you need. Complexity often exists around waiting for events to happen (the real system doesn't need notifications, but you don't want your tests to run forever when they're failing), clocks (time.Now() is difficult to test), things like that.
    - rocqua 6y ago
      Personally I am loath to add extra functionality to the real system just to make testing easier. I am massively in favor of keeping the complexity in the real system down. Adding more hooks, or increasing the interface of the real system, just to make it more testable feels wrong. This is why I'd want test to just have a lot more 'leeway' than normal code. Essentially I want heavy hooking, introspection and reflexivity but only for tests.
SideburnsOfDoom 6y ago
> Mocks work well because you can quickly define them in a given unit test and forget about it. They do, yes. But: * the mock syntax is complex and verbose. e.g. "repo.Setup(x => x.Method(It.IsAny<string>(), It.IsAny<List<int>>())) .ReturnsAsync(() => ...." is not the easiest syntax. The syntax for a fake is just regular old "class FakeFoo: IFoo" with trivial method implementations and no library needed to make it work. * the mock syntax does not scale. Your 5 lines of setup in one test does not help you in a different test class. So it gets repeated. Soon you might find that the Fake is easier to read, easier to maintain, and fewer lines of code than all the mocks. As the article says: "their self-contained nature makes them reusable as well, which lends itself to better long-term maintainability." Not all our code is "do it quickly and forget about it", especially where you see that same thing or minor variations of it done over and over again in related tests. Mocks win here when you do something different, once only. Fakes win in the opposite cases. > I can see fakes being useful in certain cases, This is true, but it's also true that Fakes are _underused_ in general in in the .NET world. People reach for mocking frameworks as if they are the only tool.
- 3np 6y ago
  AFAICT you’re not talking about mocks in general, only about automated Moq-style frameworks? A trivial mock implementation is less complex than what OP refers to as “fakes”.
  - tyrrrz 6y ago
    Can you expand on what you mean by "a trivial mock implementation"?
hackerfromthefu 6y ago
I completely agree with you
srtjstjsj 6y ago
With a fake you don't need to rewrite its behavior in every single unit test that friends on it. One fake for each datastore, shared by all tests.

ddek 6y ago

I question a lot of advice like this, and agree with you. I’d generally far rather use NSubstitute than have to write fake classes, but I can see the utility in some cases. My honest response is this: Writing tests should be quick and painless. Maintaining fakes is more painful than maintaining substitutes. Substitutes let me interrogate side effects in great detail. I’m not concerned will performance in unit tests. Ergo, substitutes are quicker and less painful, so IMO that’s a win. But for real though, why should anyone care about someone else’s test architecture, of all things. As long as you neither under- or over-testing, why on earth does it matter?

doubletgl 6y ago
> why should anyone care about someone else’s test architecture, of all things. As long as you neither under- or over-testing, why on earth does it matter? If you have to maintain tests written by other devs you might start to care. Devs apply different patterns to writing tests and show different amounts of discipline doing so. Some produce lots of duplication ("it doesn't matter, it's just a unit test"), others prefer a complete setup and tear-down before and after every little assertion. I've seen things..
- andix 6y ago
  I've seen unit tests that test around bugs. Once you fix the bug, a lot of tests fail. Then you discover there is no easy fix for the test. Either delete them all or replace them with new ones.
deleted 6y ago
[deleted]

jrockway 6y ago

I tried to distill down the basics a few years ago in a 1 page article: https://testing.googleblog.com/2013/06/testing-on-toilet-fake-your-way-to.html https://testing.googleblog.com/2013/06/testing-on-toilet-fak... The example is a little contrived, but the whole article fits on one sheet of paper and does yield a better test than mocks would. Testing against the real system is always better than testing against a fake. That should be your first preference, and if you can modify the system to make testing against it easier, that's even better. Sometimes you can't, and if your interaction is complicated and the parts that you care about are simple, a fake can get you good confidence that your part works. Mocks just feel like writing the code again -- in your code, you write "call a function with an argument, then call another function with an argument" and in the tests you write "pass if a function is called with an argument, and again with an argument". It can be the right thing at the right time, but it's usually writing a test to make some automated linter shut up. And that's a complete waste of time.

rocqua 6y ago
> if you can modify the system to make testing against it easier, that's even better. What do you mean here? Changing your testing system, or changing the real system?
- jrockway 6y ago
  Changing the real system to add the hooks you need. Complexity often exists around waiting for events to happen (the real system doesn't need notifications, but you don't want your tests to run forever when they're failing), clocks (time.Now() is difficult to test), things like that.
  - rocqua 6y ago
    Personally I am loath to add extra functionality to the real system just to make testing easier. I am massively in favor of keeping the complexity in the real system down. Adding more hooks, or increasing the interface of the real system, just to make it more testable feels wrong. This is why I'd want test to just have a lot more 'leeway' than normal code. Essentially I want heavy hooking, introspection and reflexivity but only for tests.

SideburnsOfDoom 6y ago

> Mocks work well because you can quickly define them in a given unit test and forget about it. They do, yes. But: * the mock syntax is complex and verbose. e.g. "repo.Setup(x => x.Method(It.IsAny<string>(), It.IsAny<List<int>>())) .ReturnsAsync(() => ...." is not the easiest syntax. The syntax for a fake is just regular old "class FakeFoo: IFoo" with trivial method implementations and no library needed to make it work. * the mock syntax does not scale. Your 5 lines of setup in one test does not help you in a different test class. So it gets repeated. Soon you might find that the Fake is easier to read, easier to maintain, and fewer lines of code than all the mocks. As the article says: "their self-contained nature makes them reusable as well, which lends itself to better long-term maintainability." Not all our code is "do it quickly and forget about it", especially where you see that same thing or minor variations of it done over and over again in related tests. Mocks win here when you do something different, once only. Fakes win in the opposite cases. > I can see fakes being useful in certain cases, This is true, but it's also true that Fakes are _underused_ in general in in the .NET world. People reach for mocking frameworks as if they are the only tool.

3np 6y ago
AFAICT you’re not talking about mocks in general, only about automated Moq-style frameworks? A trivial mock implementation is less complex than what OP refers to as “fakes”.
- tyrrrz 6y ago
  Can you expand on what you mean by "a trivial mock implementation"?

hackerfromthefu 6y ago

I completely agree with you

srtjstjsj 6y ago

With a fake you don't need to rewrite its behavior in every single unit test that friends on it. One fake for each datastore, shared by all tests.