Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prefer Fakes over Mocks

tyrrrz.me

Post reply on HN
Print view View original

31–40 of 125 posts

Re: Prefer Fakes over Mocks

#31

Post by csala »

Simply saying prefer "this" over "that" without adding any context to the equation is the best recipe to end up doing the wrong thing in the wrong place. Or maybe you mean that you can make the same decisions when testing a Web based app UI than when testing a cryptographic function in the Linux kernel?

IMO, both mocks, fakes and "reals" (to put it in the same language) need to be first class citizens of software testing, each one of them used in the right circumstances. Just like resorting to unit testing only is as much a bad practice as it is to use acceptance testing only.

A good testing strategy should be adapted to each software and context, and potentially include all types of tests: unit, end-to-end, integration, numerical, acceptance, etc. and all sorts of resources: mocks, dummy data, substitutes, testing engineers, test databases, real databases, real users, etc.

Re: Prefer Fakes over Mocks

#32

Post by throw_m239339 »

andix wrote: post #17
doubletgl wrote: post #6

How are fakes, as described in this article, not also implementation-aware testing?

Because they don't just implement a part of the interface (just one store method, or just one of two load methods). They try to create a fully functional fake of the original class. In this case instead of storing the blobs via a REST interface or a database connection, it just keeps it in memory. So it should mostly behave like the real implementation, but is not suitable for production, as it doesn't persist the da…

> Because they don't just implement a part of the interface (just one store method, or just one of two load methods). They try to create a fully functional fake of the original class.

So shouldn't fakes have their own tests as well? Mocks don't need tests (at least in C# with a framework) because no new class is ever written.

Anyway most of these issues are inherently linked to the nature of OOP and are a direct trade off to its benefits.

Both Mocks and Fakes have advantages and drawbacks, but the OP doesn't reflect that.

I wish articles written on that subject would take a step back and explore how code can be written so that the burden of testing is reduced to a minimum.

Re: Prefer Fakes over Mocks

#33

Post by ragnese »

doubletgl wrote: post #6

How are fakes, as described in this article, not also implementation-aware testing?

The fake is coupled to the "real" implementation of the interface. But the test that uses the fake is no longer coupled to the implementation of the fake/mock.

Instead of counting how many times a method is called (mock), your test just gets to test the outcome of the overall operation (fake).

Re: Prefer Fakes over Mocks

#34

Post by gitgud »

> "However, relying on dynamically-generated mocks can be dangerous, as it typically leads to implementation-aware testing."

I agree, tests should be simple! Dynamically generating stubs, mocks or even arguments for tests hides complexity which leads to test code that's hard to reason about... and is hard to change/fix

Re: Prefer Fakes over Mocks

#35

Post by rocqua »

tomgp wrote: post #13

A tangent, and somewhat philosophical: is "The primary purpose of software testing" really "to detect any potential defects in a program before it reaches its intended consumers"? I would argue that whilst that is a commonly held belief, and certainly true for some tests of business logic, the main value and reason for testing is to allow developers to confidently make changes to existing code. In my experience user…

I agree, but the two are very similar if you read 'defects in a program' as bugs.

Bugs can be hard to cause, and thus not be noticed by user acceptance testing. So for catching them, tests are more useful.

Re: Prefer Fakes over Mocks

#36

Post by rocqua »

silveroriole wrote: post #27
kelnos wrote: post #25

Earlier quoted context omitted.

The article addresses this: you need to write tests for the fake as well. I'm not sure I buy this as something that's desirable to have to do, but it should address your concern.

Hmm, if I’m having to write tests for my tests, I feel something has gone wrong in my life ;)

If this leads to having to spend less time on writing tests in total, things have gone right.

These fakes are much less maintenance heavy. As changes to implementation details don't require changes to tests. Hence, whilst you need to write tests for your tests, you spend less time writing tests in total.

Re: Prefer Fakes over Mocks

#37

Post by rocqua »

jrockway wrote: post #5
Ronsenshi wrote: post #2

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.

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-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 m…

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

Re: Prefer Fakes over Mocks

#38

Post by UK-Al05 »

silveroriole wrote: post #11

The fatal flaw is that you’re really introducing a new class which may have its own behaviour problems. Now your test is implicitly testing the test class. I also prefer to see explicit mocking than just trust that the fake does what it says it will. How do I know without looking whether the fake store method REALLY stores the doc, or whether someone set it up to just return OK? And how do you test error handling - m…

Write integration tests than run against the real thing and the fake one.

Test for the relied upon behaviours.

It's essentially contract testing.

It's great objects that perform external actions.

Re: Prefer Fakes over Mocks

#39

Post by mathgladiator »

It seems to me that a Fake is really a Mock, and Mocks became this unholy dynamic framework stuff. I'm not a fan of dynamic mocks where the test code has the mocked implementation because it is super brittle. Instead, a "fake" (i.e. a mock as I understood them) is an alternatively implementation of an interface.

There are a lot of really good "fakes" out there. Fake file system which lets you simulate disk failures. Fake time and randomness to introduce determinism. Every API over network can have a fake. These are all good things to fake out as you can simulate the appropriate failures which are almost impossible to do via integration, acceptance, or E2E tests.

Post reply on HN