Feature: Backtesting with IB data about qstrader HOT 2 CLOSED

Hi Ryan,

Thanks a lot for this! I'll take a good look at it and get back to you.

Firstly, we should definitely add significant testing to the code (I'm not sure if you've done this yet) and we can come up with some unit test specifications together.

I'll add swigibpy to the requirements.txt once we're both happy with the code, and of course instructions for IB Gateway. This will obviously be platform dependent.

As for the demo account, we don't need to worry about this too much as, going forward, I'll have access to a paper-trading account we can use.

from qstrader.

Not a problem. Unit testing is complete on the Strategy component, but haven't done anything with my IBPriceHandler yet as it's still pretty rough (just getting things working and settling on the "right" approach).

I don't believe unit testing code around swigibpy or the IB components would be too useful since most of the logic is abstracted away from QStrader, so I think integration tests would be a lot more suitable, with mocks set up for the swigibpy functions used. That way we can test the full coverage of expected result from the API really quickly, but it does require a bit more leg work around mocking swigibpy up.

On a semi related historic/data-feed note;
I'm tossing up a few different market data providers at the moment (IB market data sounds a bit meh for a few reasons), so I might personally end up using a ZeroMQ-based Price Handler that reads ticks which have been emitted from a separate C program acting as a stock screener. The C program would either feed ticks in from a HDF5 DB or emit them from the realtime stream. C program can then emit raw ticks, or roll them up into OCHLV bars if required before emitting them. Main reason is that my preferred (at this stage) data provider only has a C API, and the stock-screening/tick-rolling computation might be more suited to C if I'm watching a large universe of stocks.

QStrader wouldn't need to know where they're from, which is neat, so my personal stuff is abstracted away nicely from the rest of the system. I'm not sure how you're envisioning incorporating a historic DB into the QStrader, but that's roughly the architecture I'll probably personally go with if this provider is all it's cracked up to be.

This also handles the needs of a stock-screener for me personally -- not sure how you'd plan or prefer to do stock-screening, but that's a separate topic entirely

from qstrader.