Hi, how do you best fake an rest api, i.e. a retro...

# test

[ursus]

Hi, how do you best fake an rest api, i.e. a retrofit interface?

FakeApi subclass? If so, how? Do you create an anonymous subclass and override what you need per test? Or a final class and lambdas a ctor params (then called in the functions)?

[tddmonkey]

What is it you’re actually trying to achieve?

[ursus]

integration test of sync routine

api returns x, sync happens, assert database looks like y

[tddmonkey]

So you’re testing an API?

[tddmonkey]

Do you actually want to test the API gets called, or do you want to test the result is stored in a DB?

[ursus]

well, api in this case is just GET, so not really necessary to check explicitly if it was called

[tddmonkey]

Standard approach - create an interface to represent your API class and provide a test double to the test

[ursus]

how, anonymous subclass and inline override whats needed or regular subclass with lambdas in ctor?

[tddmonkey]

Just create an interface for your api instead of a concrete class. Use the interface wherever you use the current concrete class, then in tests you can just create any kind of test double

[tddmonkey]

No need for subclasses or injecting lambdas

[ursus]

no I mean how do you create the test double, anonymous subclass or something else?

[tddmonkey]

You just implement the interface I described above

[tddmonkey]

https://www.codurance.com/publications/2019/04/08/introduction-to-test-doubles

[ursus]

so a single concrete implementation class, with all return values passed in via ctor?

i feel like that will contain lot of unrelared setup, if ig were lambdas, you could throw in lambda, and have that as default param

[tddmonkey]

You can do it whichever way you like. Just be aware that there isn’t a “one size fits all” solution. Return values in a constructor, hardcoded values, programmable values, lambda return, anything else - they all have their place. If you have a lot of setup to do just for a single test though you might want to look at your design. For example, if your FakeApi has loads of methods and you need to set that up, extract a smaller interface that your code under test needs and have your FakeApi implement that. You only need to do the setup required for your test then.

[ursus]

sure, most ergonomi would be anonymous subclass and override whats needed but i dont like the syntax

[wakingrufus]

i use mock server when I want to avoid mocking out code in my runtime, and let it run like it does in production (ie integration test): https://www.mock-server.com/mock_server/running_mock_server.html#client_api