4 ms·

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 a

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
  all these require state and the syntax & semantics of the exchange, which is not under your control in the real world
  - pyrale 3y ago
    > state You don't need the exchange's state to decide what case you are testing > syntax Well, if you don't split parsing in a separate component, yes, you need to test it. > semantics You work on your own component's semantics, not the exchange's. You don't need to test that.
    - zabzonk 3y ago
      > You don't need the exchange's state to decide what case you are testing yes you do, thd exchange needs to know the state of the trade. > Well, if you don't split parsing in a separate component, yes, you need to test it no idea what you mean here > You work on your own component's semantics, not the exchange's. You don't need to test that. much the same here. i do not know what the semantics are - it's a black box, with a terribly underspecified API. so i cannot usefuly mock it.
      - pyrale 3y ago
        > yes you do, thd exchange needs to know the state of the trade. You're not testing the exchange, though.

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
all these require state and the syntax & semantics of the exchange, which is not under your control in the real world
- pyrale 3y ago
  > state You don't need the exchange's state to decide what case you are testing > syntax Well, if you don't split parsing in a separate component, yes, you need to test it. > semantics You work on your own component's semantics, not the exchange's. You don't need to test that.
  - zabzonk 3y ago
    > You don't need the exchange's state to decide what case you are testing yes you do, thd exchange needs to know the state of the trade. > Well, if you don't split parsing in a separate component, yes, you need to test it no idea what you mean here > You work on your own component's semantics, not the exchange's. You don't need to test that. much the same here. i do not know what the semantics are - it's a black box, with a terribly underspecified API. so i cannot usefuly mock it.
    - pyrale 3y ago
      > yes you do, thd exchange needs to know the state of the trade. You're not testing the exchange, though.