5 ms·

If I have a function that hits a JSON API and returns a path from the resultant object and I mock that API to return 4, I'm doing exactly that. I can write a m

If I have a function that hits a JSON API and returns a path from the resultant object and I mock that API to return 4, I'm doing exactly that. I can write a mock for every data type the API could return and one for every error the API can return and test all of them near-instantly without having to do a HTTP round trip to the fake server (which presumably also now needs configuring before each test)

zabzonk 3y ago
i think you either over-estimate the complexity of your json api call, or under-estimate how complex accessing a stock exchange is
- lexicality 3y ago
  anything is mockable if your code is broken into smaller easy to reason about easy to test chunks and you have a complete understanding of what the thing you're mocking is able to do. If you don't have a complete understanding of what it's able to do then I think how you write your tests is the least of your worries.
  - zabzonk 3y ago
    > anything is mockable true. but to mock something like a stock exchange, you are basically going to have to write a stock exchange (and mocked other clients than your client app). and then you are going to have to test that mock. this could all take a while. i really don't think that people who suggest mocking realise how complex applications work and how they are always changing their interfaces - for SEs due to regulatory pressures, for example.
    - pyrale 3y ago
      > true. but to mock something like a stock exchange, you are basically going to have to write a stock exchange All your mock has to do is to provide the specific answer you're expecting to receive from that service in the specific case you're testing. In most situations, re-imlementing logic in a mock is a mistake that should be avoided.
      - zabzonk 3y ago
        with a stock exchange, it's a dialog - don't expect any particular response. for example - using sell and buy just to keep things simple, and i am the seller and i could not be bothered looking up real prices or tickers: sell 10000 BT at 50GBP // i put this on the exchange buy 500 // somebody bought some buy 2000 // somebody else (or maybe the same) bought some crash // exchange crashed (not rare) we recover cancel 500 // they can do this in a limited window buy 8000 // we have filled you see, it isn't simple, but that is about as simple as you get
        hiatus 3y ago
        Wouldn't each of these be a test case?
        zabzonk 3y ago
        only if you have a stateful mock server with multiple mock clients attached to it. for example, when you put a sell on the server, you are basically going to be listening on a socket for multiple responses and what the responses are will depend on the buyers (which you must also mock). and don't get me started on buying, ticker conversions between different exchanges, currency, time, etc. it is too hard to mock. to mitigate this some exchanges, such as london and paris, do provide test exchanges, which are crap, and available every other fridays, or whatever. when i worked in this area, my boss used to test my code by putting a trade on the exchange and then immediatly cancelling it. this was illegal, as he wasn't a licensed trader, and the exchanges got enraged. i refused to have anything to do with it. but my point is - you cannot do meaningful unit tests on very complex systems. even integration tests can be very hard, but are worthwhile.
        RussianCow 3y ago
        > but my point is - you cannot do meaningful unit tests on very complex systems. I think you're missing the point: unit tests should not be testing entire systems; that's the point of integration or end-to-end tests, which are different beasts entirely. You can very much write unit tests against parts of a complex system because each test should only be testing one isolated bit of functionality in the form of inputs (including local state) and outputs.
tsimionescu 3y ago
Reimplementing a whole complex API with mocks is not exactly quick or easy or less error prone than the code that should interact with that API.
- lexicality 3y ago
  if your test implements a whole complex API then it's not a unit test
- MoreQARespect 3y ago
  It can be fairly quick with tools like mitmproxy.
- pyrale 3y ago
  The point of mocking is not to reimplement a service you depend on, it is to provide the answer that service would give in the specific example you're testing.
  - zabzonk 3y ago
    but suppose that service could give all sorts of different responses, depending on (say) the time of day and the country originating the request.
    - pyrale 3y ago
      What's relevant to you is your element under test, not the dependency. Does the component you're testing have a different behaviour for each different response? If yes, you're out of luck (but also, maybe you should split it in multiple components). If not, then you probably don't need to test every possible response the dependency returns.
      - 8n4vidtmkvmk 3y ago
        You're not out of luck. Your testing framework should allow you to hardcode different responses to different requests. Include the time in the response if you need to, it shouldn't be hard. I've started adding random elements to my mock responses to force other developers to not assert things that aren't relevant to the test.

zabzonk 3y ago

i think you either over-estimate the complexity of your json api call, or under-estimate how complex accessing a stock exchange is

lexicality 3y ago
anything is mockable if your code is broken into smaller easy to reason about easy to test chunks and you have a complete understanding of what the thing you're mocking is able to do. If you don't have a complete understanding of what it's able to do then I think how you write your tests is the least of your worries.
- zabzonk 3y ago
  > anything is mockable true. but to mock something like a stock exchange, you are basically going to have to write a stock exchange (and mocked other clients than your client app). and then you are going to have to test that mock. this could all take a while. i really don't think that people who suggest mocking realise how complex applications work and how they are always changing their interfaces - for SEs due to regulatory pressures, for example.
  - pyrale 3y ago
    > true. but to mock something like a stock exchange, you are basically going to have to write a stock exchange All your mock has to do is to provide the specific answer you're expecting to receive from that service in the specific case you're testing. In most situations, re-imlementing logic in a mock is a mistake that should be avoided.
    - zabzonk 3y ago
      with a stock exchange, it's a dialog - don't expect any particular response. for example - using sell and buy just to keep things simple, and i am the seller and i could not be bothered looking up real prices or tickers: sell 10000 BT at 50GBP // i put this on the exchange buy 500 // somebody bought some buy 2000 // somebody else (or maybe the same) bought some crash // exchange crashed (not rare) we recover cancel 500 // they can do this in a limited window buy 8000 // we have filled you see, it isn't simple, but that is about as simple as you get
      - hiatus 3y ago
        Wouldn't each of these be a test case?
        zabzonk 3y ago
        only if you have a stateful mock server with multiple mock clients attached to it. for example, when you put a sell on the server, you are basically going to be listening on a socket for multiple responses and what the responses are will depend on the buyers (which you must also mock). and don't get me started on buying, ticker conversions between different exchanges, currency, time, etc. it is too hard to mock. to mitigate this some exchanges, such as london and paris, do provide test exchanges, which are crap, and available every other fridays, or whatever. when i worked in this area, my boss used to test my code by putting a trade on the exchange and then immediatly cancelling it. this was illegal, as he wasn't a licensed trader, and the exchanges got enraged. i refused to have anything to do with it. but my point is - you cannot do meaningful unit tests on very complex systems. even integration tests can be very hard, but are worthwhile.
        RussianCow 3y ago
        > but my point is - you cannot do meaningful unit tests on very complex systems. I think you're missing the point: unit tests should not be testing entire systems; that's the point of integration or end-to-end tests, which are different beasts entirely. You can very much write unit tests against parts of a complex system because each test should only be testing one isolated bit of functionality in the form of inputs (including local state) and outputs.

tsimionescu 3y ago

Reimplementing a whole complex API with mocks is not exactly quick or easy or less error prone than the code that should interact with that API.

lexicality 3y ago
if your test implements a whole complex API then it's not a unit test
MoreQARespect 3y ago
It can be fairly quick with tools like mitmproxy.
pyrale 3y ago
The point of mocking is not to reimplement a service you depend on, it is to provide the answer that service would give in the specific example you're testing.
- zabzonk 3y ago
  but suppose that service could give all sorts of different responses, depending on (say) the time of day and the country originating the request.
  - pyrale 3y ago
    What's relevant to you is your element under test, not the dependency. Does the component you're testing have a different behaviour for each different response? If yes, you're out of luck (but also, maybe you should split it in multiple components). If not, then you probably don't need to test every possible response the dependency returns.
    - 8n4vidtmkvmk 3y ago
      You're not out of luck. Your testing framework should allow you to hardcode different responses to different requests. Include the time in the response if you need to, it shouldn't be hard. I've started adding random elements to my mock responses to force other developers to not assert things that aren't relevant to the test.