- verify that the alpaca-backtrader framework works reliably in paper/live trading and behaves exactly as in backtest mode
- this test aims to replicate a real trading scneario, where the programmer wants full controll of the order flow of main-orders and stop-orders
- stop-orders have to be cancelled before positions are closed, otherwise Alpaca will rejected the closing order
- only after a mainorder is 100% filled, the stop-order should be created - this is achieved by creating the stop-loss order in the "notify_order" function, when the mainside market order is "Completed"
- while backtrader operates with parents-child orders to connect a main-order to a stop-order (with transmit=False) this functionality is not replicated by the alpaca-backtrader framework - therefore this test aims to simulate manual handling of main-orders and stop-orders and evaluate if it behaves according to the backtest
- the backtrader strategy
stoploss.pyis run first in backtest mode and then again in paper/live mode to replicate the behavior - a log is written to *.backtest.log and *.paperlive.log
- the log is then parsed and the events evaluated according to expected behaviors
- for example, before a position is closed, the stop-loss order has to be cancelled first, which has to result in 2 notify_order events (cancel the stop-order, completed sell event)
- the strategy opens a long position and upon completion a stop-loss order to cover the downside
- either a stop-loss occurs within 2 bars or after 2 bars the position is closed with an "expiration" close order
- following, a short position is open, again with a stop-loss order to protect from rising prices
- again, either a stop-loss occurs within 2 bars or after 2 bars the position is closed with an "expiration" close order
- this cycle is repeated, until
EXPIRATION_BARSis reached
- do notify_order messages work as expected for Market and Stop-Market orders (Accepted, Completed, Canceled)?
- does notify_order event occur after Stop/Market order is canceled by the strategy?
- does notify_order event occur after Stop order is triggered by Alpaca?
- are there duplicate event messages or exactly one message per event as expected? (this is crucial, otherwise one cannot place trading logic in the
notify_orderfunction) - review test_notifymessages.py fo details
- docker-compose
sudo curl -L "https://github.com/docker/compose/releases/download/1.25.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose;
sudo chmod +x /usr/local/bin/docker-compose;
- docker
sudo apt update ;
sudo apt install apt-transport-https ca-certificates curl software-properties-common;
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -;
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable";
sudo apt update;
sudo apt-cache policy docker-ce;
sudo apt install docker-ce -y;
sudo systemctl status docker;
- clone the repo:
git clone - enter API keys in
ENV.sh bash _run.sh
- customize the
Dockerfileor create your own to test different package / python versions - specify the Dockerfile to test in
docker-compose.yml - in
stoploss.pyEXPIRATION_BARSnumber of 1-min bars after which position is closed automatically (expired)STOP_BARSnumber of 1-min bars after which the test is completedSTOP_LOSS_PERCthe stoploss level after main order
i made the following observations
- soemtimes (not always), no notify_order messages are sent when stoploss order is canceled or completed (order status is updated though on the object)...this makes it not possible to trigger orders from the notify_order function
- there are duplicated notify_order messages, not allowing a programmer to place trading logic in the
notify_orderfunction)
currently not possible, the stop-order was stored during last runtime in the order object. it is better to cancel all pending orders upon relaunch
TBD