4 ms·

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

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.
    - pyrale 3y ago
      I'm not sure what's the component under test and what's the dependency here. But I don't see this as particularly complex to test. Assuming you're writing a client: - use the client to send a sell order, check that you handle properly the ack (or lack thereof) of the trading platform. - check that the client handles properly a buy order received from the platform. - check that the client handles properly a cancel order. - check that when an order is filled, the client closes it properly after the cancel window is closed. - check that the client recovers properly after a crash. To do this, assuming the platform is a dependency of the client, in each test case, you have to implement one or two hardcoded messages from the platform.

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.
  - pyrale 3y ago
    I'm not sure what's the component under test and what's the dependency here. But I don't see this as particularly complex to test. Assuming you're writing a client: - use the client to send a sell order, check that you handle properly the ack (or lack thereof) of the trading platform. - check that the client handles properly a buy order received from the platform. - check that the client handles properly a cancel order. - check that when an order is filled, the client closes it properly after the cancel window is closed. - check that the client recovers properly after a crash. To do this, assuming the platform is a dependency of the client, in each test case, you have to implement one or two hardcoded messages from the platform.