Test Exchange

[jcrosby]

Is there any interest in a fake/test exchange that uses all of the same interfaces as the other exchanges, but can be loaded with any series of ticker data? I feel this could be useful for testing strategies and execution engines, but perhaps I am missing something that is already useful for this?

[timmolter]

Ah, so like a historical data feeder for backtesting algorithmic trading strategies?

[jcrosby]

Yes, exactly. I am happy to begin work on a pull request if there is interest.

[timmolter]

I really like the idea. I hesitate though because it's a feature that is a bit out of the scope of XChange. We recently turned down the idea of adding an arbitrage API to XChange.

If we can do it as a self-contained module that basically emulates a live exchange, that'd be nice though. Then in the xchange-examples module, we could have a simple example app that uses that new module.

We could probably accomplish this without running some kind of embedded json server too.

I'm interested. Would you be willing to put together a small plan with some more details??

[jcrosby]

Sure. I will put together a small plan and reply back to this thread.

[jcrosby]

It looks like there are at least a couple of ways to do this.

One method might be to create an exchange called BacktestExchange, for example, and allow setting a starting balance plus a series of trade and market events. In the case of a PollingMarketDataService, each call to something like getTrades could simply return the next batch of data in the pre-determined queue. Executing a trade using the PollingTradeService would update the balance minus configurable fees, lag, slippage, etc.

A second method that comes to mind is to simply extend each of the concrete classes in a specific exchange, replacing http client calls with fetches from the pre-determined series of trades and market data. There could possibly be one of these for each exchange but given the nice abstraction of this project across all exchanges, it might not make sense to have more than one.

Those are my rough thoughts so far. What do you think? I would like to stick within the vision for this project. If this idea doesn't fit well, I can certainly spin up another focused project that depends on this one in order to experiment. In either case, your work is very clear and easy to follow so thank you for sharing it.

[timmolter]

Thanks for laying out your thoughts on this.

After reading your ideas, I think the best approach would be to do this in 2 main pieces....

1) BacktestExchange module in XChange

Like you said: "each call to something like getTrades could simply return the next batch of data in the pre-determined queue."

2) TraderBot (or whatever a better name would be), which is a new project maintained by you.

I would take what you said as part of you first method and put it in this new project: "allow setting a starting balance plus a series of trade and market events" and "update the balance minus configurable fees, lag, slippage, etc".

In summary the BacktestExchange module would ONLY know about serving data. TraderBot would then keep track of all the things like balance, fees, order logic, etc. You could plug your own trade logic into TraderBot.

How does that sound to you?

(BTW, lag isn't integrated into any exchange module yet, but I was probably going to add it to the MtGox module.)

[jcrosby]

Sounds good. Pull request(s) forthcoming.

[timmolter]

Awesome!

I bet you already saw this, but just in case not, because it has some good info: https://github.com/timmolter/XChange/wiki/New-Implementation-Best-Practices

Also, to start you could just add a package in xchange-examples for a basic traderbot to get going.

Good luck!

[timmolter]

closing due to no further progress on this front.