4 ms·

Can someone explain to me what this is all about? Shouldn't you hide all your API calls behind an interface, and then mock that interface? Dependency inversion

by peheje 6y ago

Can someone explain to me what this is all about? Shouldn't you hide all your API calls behind an interface, and then mock that interface? Dependency inversion principle, depend upon abstractions and all that.

emilsedgh 6y ago
I personally am not a fan of too many abstractions. If the only reason for abstraction is testing, then mocking an interface seems like a more valid choice to me.
- xadoc 6y ago
  The abstraction is there because in many static languages you will immediately have two implementations, the infrastructure one (database, API call, 3rd party) and the tests.
- jjpe 6y ago
  > I personally am not a fan of too many abstractions. Then you're likely in the wrong business, since most of what programming is is dealing with the various facets of one abstraction or another.
  - TomMarius 6y ago
    This is definitely a valid approach to software development, e.g. in embedded development (where you still might need to call APIs).
  - emilsedgh 6y ago
    Absolutely. I'm not saying I don't want to abstract anything or deal with any abstractions which can lead to ridiculous code [0]. I just prefer to abstract when I have more reasons that just testing. That can be done using mocking techniques. https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr...
BiteCode_dev 6y ago
You still need to test the abstraction.
HiddenCanary 6y ago
For me, this is part of the design and development phase to help me plan the API structure and also to provide test API data mocks to the frontend, so that frontend doesn't have to wait on the backend to finish development before they can start.
djohnston 6y ago
What does mocking an interface mean, like a mock implementation? How is that different then defining an API and then having stub methods on the front returning pretend data?
- gitgud 6y ago
  I think they mean wrapping the REST api in a class (aka "data provider" or "repository pattern") this way you've abstracted the HTTP request logic away from your application. Both the API and the Mock implementation will require the same interface.
pydry 6y ago
I've gone through this process a few times: 1) Join a project and fume about how they didn't write nice, clean, "testable" code. 2) Build some sort of integration testing framework that also mocks out REST API calls relatively cheaply (e.g. using recording/playback against a live system). 3) Realize that I can now refactor the code such that it is nice, clean and more easily "unit testable". 4) Realize that with an effective and easy to use, fast integration testing framework the lack of dependency inversion doesn't bother me nearly as much as it used to. 5) Wonder if dependency inversion is actually more of a hack to deal with the sheer utter crappiness of unit tests... and whether making vast architectural changes to code in order to accommodate the sheer ineffectiveness of the current state of test tooling is really the height of wisdom after all. In a number of these projects there were noises about rewriting the whole damn thing in a different language (usually because management wanted to consolidate hiring around fewer languages), and it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests.
- bjterry 6y ago
  > it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests. I think this basically already exists with "Cucumber" and behavior-driven development. The test definition is specified in a natural-language-looking DSL which supports a number of underlying languages. When you swapped out the system you would have to implement the step definitions in the new language, but the tests would remain valid.
- moreaccountspls 6y ago
  Totally agree with you. I think the industry is going through an "emperor has no clothes" thing with unit tests and dependency inversion at the moment. The creator of BDD gave this talk a few years ago, which resonated with me: https://www.youtube.com/watch?v=4Y0tOi7QWqM https://www.youtube.com/watch?v=4Y0tOi7QWqM > it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests. This is exactly what I've been doing and advocating for for a while. Don't mock things like databases at all in your code. If you want to use a mock, use a "first class" mock like https://cloud.google.com/bigtable/docs/emulator https://cloud.google.com/bigtable/docs/emulator. The other thing is that TDD was born in a world where containers aren't the norm. All the pain of higher level testing really comes up from setting up an appropriate environment. If you're already using Docker or k8s, that pain is pretty much 0.
anonymoushn 6y ago
Some reasons not do to that: - Now it's harder to navigate my codebase because I introduced an extra layer of indirection everywhere only for the sake of testing. - If there is some difference between how the actual protocol client and actual upstream behave and how my fake interface behaves in test, my tests will be wrong, and I will find out when I push to prod. If my tests exercised the actual code that speaks the actual protocol to a fake upstream, I may have caught the issue in the tests. - If I ever want to replace the process entirely with a completely different one, I must now throw away my tests. If my tests tested the end-to-end behavior of the system, I would be able to keep my tests.
- borland 6y ago
  What I find works well is to use dependency inversion to mock things out within your code, but mock out the transport layer. I.e: If you have a "stack" like this: - Application - MainService - ApiService - HttpClient What you might think of doing is replacing the ApiService with a mock, such that you can test your MainService's interactions with it. You can do that, sure, and it's useful - but as you rightly point out now you can't find any bugs in your ApiService. Instead, mock out the HttpClient (or if it's not Http, mock out the Socket). Typically because these kinds of things are at the bottom of the stack, they have very simple interfaces and are really easy to mock, and because the interfaces are so simple the mocks don't introduce much - if any - damage to the rest of your code around them. There are significant advantages to doing it this way too, over using an external mocked API. - Way faster - More reliable - Single codebase (if the mock API is some external NodeJS thing now you have to wrangle that too) - You have perfect control over timing. For example, if you have a bug in your ApiService which happens when two packets get interleaved in exactly the wrong way, you can reproduce this easily. If you had a real HttpClient talking to an external process it's nigh impossible. Good luck!
  - paledot 6y ago
    All good points, but you missed the most important part: in any mature programming language, you're not implementing the HttpClient yourself: it's a library, package, bundle, whatever. Which means that when you mock that you're not missing out on testing any code that you wrote, and the project that maintains your HttpClient (hopefully) has their own community-maintained test suite.
bspammer 6y ago
Definitely you should do that, but it's still useful to have automated API tests too. That way you can upgrade client libraries risk free (and even automate these upgrades with tools like https://dependabot.com/ https://dependabot.com/). If your tests are green then you're good.

by peheje 6y ago

emilsedgh 6y ago

I personally am not a fan of too many abstractions. If the only reason for abstraction is testing, then mocking an interface seems like a more valid choice to me.

xadoc 6y ago
The abstraction is there because in many static languages you will immediately have two implementations, the infrastructure one (database, API call, 3rd party) and the tests.
jjpe 6y ago
> I personally am not a fan of too many abstractions. Then you're likely in the wrong business, since most of what programming is is dealing with the various facets of one abstraction or another.
- TomMarius 6y ago
  This is definitely a valid approach to software development, e.g. in embedded development (where you still might need to call APIs).
- emilsedgh 6y ago
  Absolutely. I'm not saying I don't want to abstract anything or deal with any abstractions which can lead to ridiculous code [0]. I just prefer to abstract when I have more reasons that just testing. That can be done using mocking techniques. https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr...

BiteCode_dev 6y ago

You still need to test the abstraction.

HiddenCanary 6y ago

For me, this is part of the design and development phase to help me plan the API structure and also to provide test API data mocks to the frontend, so that frontend doesn't have to wait on the backend to finish development before they can start.

djohnston 6y ago

What does mocking an interface mean, like a mock implementation? How is that different then defining an API and then having stub methods on the front returning pretend data?

gitgud 6y ago
I think they mean wrapping the REST api in a class (aka "data provider" or "repository pattern") this way you've abstracted the HTTP request logic away from your application. Both the API and the Mock implementation will require the same interface.

pydry 6y ago

I've gone through this process a few times: 1) Join a project and fume about how they didn't write nice, clean, "testable" code. 2) Build some sort of integration testing framework that also mocks out REST API calls relatively cheaply (e.g. using recording/playback against a live system). 3) Realize that I can now refactor the code such that it is nice, clean and more easily "unit testable". 4) Realize that with an effective and easy to use, fast integration testing framework the lack of dependency inversion doesn't bother me nearly as much as it used to. 5) Wonder if dependency inversion is actually more of a hack to deal with the sheer utter crappiness of unit tests... and whether making vast architectural changes to code in order to accommodate the sheer ineffectiveness of the current state of test tooling is really the height of wisdom after all. In a number of these projects there were noises about rewriting the whole damn thing in a different language (usually because management wanted to consolidate hiring around fewer languages), and it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests.

bjterry 6y ago
> it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests. I think this basically already exists with "Cucumber" and behavior-driven development. The test definition is specified in a natural-language-looking DSL which supports a number of underlying languages. When you swapped out the system you would have to implement the step definitions in the new language, but the tests would remain valid.
moreaccountspls 6y ago
Totally agree with you. I think the industry is going through an "emperor has no clothes" thing with unit tests and dependency inversion at the moment. The creator of BDD gave this talk a few years ago, which resonated with me: https://www.youtube.com/watch?v=4Y0tOi7QWqM https://www.youtube.com/watch?v=4Y0tOi7QWqM > it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests. This is exactly what I've been doing and advocating for for a while. Don't mock things like databases at all in your code. If you want to use a mock, use a "first class" mock like https://cloud.google.com/bigtable/docs/emulator https://cloud.google.com/bigtable/docs/emulator. The other thing is that TDD was born in a world where containers aren't the norm. All the pain of higher level testing really comes up from setting up an appropriate environment. If you're already using Docker or k8s, that pain is pretty much 0.

anonymoushn 6y ago

Some reasons not do to that: - Now it's harder to navigate my codebase because I introduced an extra layer of indirection everywhere only for the sake of testing. - If there is some difference between how the actual protocol client and actual upstream behave and how my fake interface behaves in test, my tests will be wrong, and I will find out when I push to prod. If my tests exercised the actual code that speaks the actual protocol to a fake upstream, I may have caught the issue in the tests. - If I ever want to replace the process entirely with a completely different one, I must now throw away my tests. If my tests tested the end-to-end behavior of the system, I would be able to keep my tests.

borland 6y ago
What I find works well is to use dependency inversion to mock things out within your code, but mock out the transport layer. I.e: If you have a "stack" like this: - Application - MainService - ApiService - HttpClient What you might think of doing is replacing the ApiService with a mock, such that you can test your MainService's interactions with it. You can do that, sure, and it's useful - but as you rightly point out now you can't find any bugs in your ApiService. Instead, mock out the HttpClient (or if it's not Http, mock out the Socket). Typically because these kinds of things are at the bottom of the stack, they have very simple interfaces and are really easy to mock, and because the interfaces are so simple the mocks don't introduce much - if any - damage to the rest of your code around them. There are significant advantages to doing it this way too, over using an external mocked API. - Way faster - More reliable - Single codebase (if the mock API is some external NodeJS thing now you have to wrangle that too) - You have perfect control over timing. For example, if you have a bug in your ApiService which happens when two packets get interleaved in exactly the wrong way, you can reproduce this easily. If you had a real HttpClient talking to an external process it's nigh impossible. Good luck!
- paledot 6y ago
  All good points, but you missed the most important part: in any mature programming language, you're not implementing the HttpClient yourself: it's a library, package, bundle, whatever. Which means that when you mock that you're not missing out on testing any code that you wrote, and the project that maintains your HttpClient (hopefully) has their own community-maintained test suite.

bspammer 6y ago

Definitely you should do that, but it's still useful to have automated API tests too. That way you can upgrade client libraries risk free (and even automate these upgrades with tools like https://dependabot.com/ https://dependabot.com/). If your tests are green then you're good.