Fake repositories

[yereby]

Hi Valentina,
A quick follow up for this discussion https://www.youtube.com/watch?v=IZWLnn2fNko&lc=Ugx7cWRzBUSWlUqYNLJ4AaABAg about the fake repositories.

To test the use cases you said that it is better to create fake repositories. That's clear, and i understand why; but i am not sure of a thing when talking about in-memory database.

I have a repository that call a dao for the in-memory db (and other types of db). I implemented a sort for the results from this db.
My repository passes the sort parameters to my dao, the dao handle it, and then return the items sorted, for example for a findAll().

So to test my use case, i made a fake repository. The problem is then that i have to re-implement the sort algorithm of the dao in my fake repo. Which create duplication.

What do you think about that? Maybe that's the case where we have to add tests outside the use cases? But it feels to me that the use case is not fully tested.

Thank you :)
Jérémy.

[PCreations]

Hi Jérémy :)

As you pointed out, it is useless to replicate the sorting algorithm because the database do it well for you.

Here, you want to be able to configure your fake repository with "stub results" given a pre defined order. You'll need to assert on the received params too.

Basically you'll want to expose the contract of the sorting algorithm in your repository interface. That the sort parameters you're talking about.
Then, for each test case you need to configure the expected sorted response that your findAll method will return. And assert that the methods received the correct argument.

Then, you'll eventually need a focused integration test to test the real adapter implementation (thus relying this time on the real db sorting algorithm)

[yereby]

Thanks for your reply.
I am in JS, so perhaps the good way would be to pass the wanted result in the constructor of the fake repository.

I put in the test case something like

const userRepository = new FakeUserRepository(items)

Where items initialize the items in the repository, which just return them from its findAll to the use case.
And then i spy those call in the test to be sure of the params passed by the use case to the repository.

Thanks a lot PCreations :)

[PCreations]

That's exactly what I meant :)

[valentinajemuovic]

@yereby, good question. My presentation showed only the usage of Fakes, but the wider list is: Dummies, Stubs, Spies, Mocks, Fakes. https://martinfowler.com/bliki/TestDouble.html

• Stubs provide canned responses. So, for example, a StubRepository may always return John, Mary, Mike (these could be hard-coded in the StubRepository or it could be configurable, i.e. passing these in the constructor). There is NO logic within the StubRepository, so there's a method getCustomersOrderedByFirstName(), the Stub would NOT do any sorting, the Stub returns just a canned response.

• Fakes have a working implementation, simulating the real adapter except they have to run in-memory. So for example, implementing an InMemoryRepository, it would have methods like Add, Update, Delete and may work on an in-memory List/HashMap, etc. It acts like the real thing. For a method getCustomersOrderedByFirstName(), the Stub repository would do sorting on the list.

From Uncle Bob's article https://blog.cleancoder.com/uncle-bob/2014/05/14/TheLittleMocker.html

• "fakes have real business behavior; stubs do not"
• "We can say that a Mock is a kind of spy, a spy is a kind of stub, and a stub is a kind of dummy. But a fake isn’t a kind of any of them. It’s a completely different kind of test double."

For this reason, when using Fakes, we have to write contract tests for the Fake (but don't write contract tests for spies)

@PCreations, as far as I know, the example you mentioned above is an example for Stub approach, because the method is returning a precanned response, and not doing any logic (no sort logic). Overall, yes, this is a common approach.

Difference Perspectives

These are the preferences I've seen:

• In Uncle Bob's examples, he tends to use Stubs, sometimes Spies. Doesn't really use Fakes.
• Steve Freeman, Nat Price show usage of Mocks
• "Software Engineering at Google" has a preference for fakes. "A fake is preferred over other test double techniques because it behaves similarly to the real implementation" (Chapter 13. Test Doubles, overall they advocate for Fakes, indicating limitations with Stubs and Mocks)
• Dave Farley, I've mainly seen him using Fakes

I also had a LinkedIn post regarding various thoughts on Test Doubles https://www.linkedin.com/posts/valentinacupac_tdd-testdrivendevelopment-unittesting-activity-6898896081627738112-TVsT

My personal journey:

1. I started with Mocks. Then preference shifted to Stubs/Spies
2. Currently, my preference is for Fakes, reasons outlined are those in "Software Engineering at Google". I like Fakes because when I made a contract test for a fake I can use it against the real implementation, also I get high re-use across tests, reduced test setup. Actually, to be more precise, I use a configurable Fake, which in the positive sense exhibits behavior as the real implementation but can be configured to throw exceptions if I want to simulate failure.

[yereby]

Fakes have a working implementation, simulating the real adapter except they have to run in-memory. So for example, implementing an InMemoryRepository, it would have methods like Add, Update, Delete and may work on an in-memory List/HashMap, etc. It acts like the real thing. For a method getCustomersOrderedByFirstName(), the Stub repository would do sorting on the list.

So basically if we have an in memory database we can use it in the tests ?
This is what i was doing at first try. I have an repository which call an inmemory database That i can fill at the setup of the test.

I already implemented this in memory database so i must say this is far simple for me to use it. And what is simple fells better to me :)

[valentinajemuovic]

@yereby yes, that's right. So when using fakes, you'd implement an in-memory repository, so yes, that's what I currently prefer - usage of fakes (more precisely configurable fakes). I call it FakeOrderRepository, someone else may call it InMemoryOrderRepository, same thing.

However, as I mentioned there are different perspectives regarding test doubles - because fakes is one pathway, the other pathway is stubs/spies/mocks.

P.S. Another example of in-memory repository usage in a test is in this example by @mica16 https://github.com/mica16/BDD-TDD-Demo/blob/master/src/test/java/unit/BookVTCTest.java

[PCreations]

@yereby I tend to prefer the term FakeRepository instead of InMemory because some people might think you're talking about real in-memory database implementation like sqlite for example, and that is NOT what we want.

@valentinacupac Yes the response is specified but there is still a little logic, albeit it may just be a O(1) call to a Map, or a by of a filtering for example. Real stubs should not have any logic. I prefer fakes too because with stub I'll need to add one more assertion to test that the stub method was called with the correct params, whereas with fakes it's asserted by the implementation.
I do not write test for these simples fakes though, there are transitively tested through my unit tests. But this means I need to draw a line in the kind of complexity and logic I want in these fakes. My litmus test is to keep the cyclomatic complexity very low. This generally let me find fakes bug very early in my TDD process. But I do admit that I sometimes encountered some bugs that was only because of a bug in the fake itself.

[yereby]

@PCreations Actually i implemented a FakeRepository which extends the Repository and is connected to the inMemory DAO.
To be precise, my InMemory database is a real custom inMemory db, not something like sqlite, and i absolutely agree with you to avoid confusion with terms.