3 ms·

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 cl

by 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.
    - lexicality 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. No you really don't. For your given example, you configure your application state to think it has just submitted a buy order for 500 units. Then, you write a series of tests that check to see what it does if it receives - One sell order for 500 - Two sell orders for 250 - Five hundred sell orders for 1 - One sell order for 501 - One sell order for 250 but nothing else for N simulated minutes - Nothing for N simulated minutes - The exchange socket closes with an error - A sell order for -500 - A sell order for NaN - A buy order for 500 - A corrupted message - etc etc etc For unit tests you are not checking the full behaviour of the system, you are checking to see how it behaves in a very specific set of circumstances per test. If you do not know all the messages this API can reply with then just capture a few days or weeks of traffic and you can make a damn good guess from there. If your code doesn't support this level of isolation then you need to rewrite it until it can, I highly recommend "Working Effectively with Legacy Code" by Michael C. Feathers to help you.

by pyrale 3y ago

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.
  - lexicality 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. No you really don't. For your given example, you configure your application state to think it has just submitted a buy order for 500 units. Then, you write a series of tests that check to see what it does if it receives - One sell order for 500 - Two sell orders for 250 - Five hundred sell orders for 1 - One sell order for 501 - One sell order for 250 but nothing else for N simulated minutes - Nothing for N simulated minutes - The exchange socket closes with an error - A sell order for -500 - A sell order for NaN - A buy order for 500 - A corrupted message - etc etc etc For unit tests you are not checking the full behaviour of the system, you are checking to see how it behaves in a very specific set of circumstances per test. If you do not know all the messages this API can reply with then just capture a few days or weeks of traffic and you can make a damn good guess from there. If your code doesn't support this level of isolation then you need to rewrite it until it can, I highly recommend "Working Effectively with Legacy Code" by Michael C. Feathers to help you.