¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Twsapi
  2. Topics

CI-testing anyone?

Matthias Frener
 

Hi all.

We are a group of developers working on an TWS API client in Typescript for node.js
(if you do node.js Apps, might be worth having a look??;)).

Currently we look for a solution to run automated CI-testing.

The setup is no issue, but against what do should we test?

Do you use your personal paper trading account on the CI? Maybe there is a way to get a second, no-expiring paper account? Or have a "dev" account type, that cannot trade live at all but insterad create 100 paper trade account for CI-servers?

How are you doing this?

Thanks for any hints!

?

?
Nick
 

I hate to say it but to do a robust job I think you would have to have a whole separate project that simulates TWS and the exchanges. You then connect to that for (most of) your testing.

Anything your framework does that depends on market actions (order fills, account updates, recovery from outages, etc.) won't have a way to be repeatable in a paper account.

Of course you'd also want to test against a paper account to verify that basic request and response processing is working.

This could turn out to be one of the situations where the testing framework is a much bigger project than the original project.

On 2/19/2021 4:33 PM, Matthias Frener wrote:

Currently we look for a solution to run automated CI-testing.

The setup is no issue, but against what do should we test?
 

Isolate the two parts, exchange connectivity is one part, and actually has a quite finite list of tests. The data processing and historical replication is a different problem that can be solved independent of the tws implementation.

Best wishes,


M


On Fri, 19 Feb 2021, 22:00 Nick, <news1000@...> wrote:
I hate to say it but to do a robust job I think you would have to have a
whole separate project that simulates TWS and the exchanges. You then
connect to that for (most of) your testing.

Anything your framework does that depends on market actions (order
fills, account updates, recovery from outages, etc.) won't have a way to
be repeatable in a paper account.

Of course you'd also want to test against a paper account to verify that
basic request and response processing is working.

This could turn out to be one of the situations where the testing
framework is a much bigger project than the original project.

On 2/19/2021 4:33 PM, Matthias Frener wrote:
>
> Currently we look for a solution to run automated CI-testing.
>
> The setup is no issue, but against what do should we test?
>
 

My CI testing follows what Mark outlines.??
My code is in Java.? I wrote a broker interface which limits the IB API pieces I use.? I then use a mock class framework (Mockito) to simulate responses.? This of course doesn't simulate TWS, but at least allows for testing of my code.

But sometimes weird things happen in production and TWS doesn't do what you expect, so an idea I had was to implement a TWS API "recorder" so I can record/replay IB API events to diagnose problems that come up in production.? Then use those event records to generate test cases.
Joel Gross
 

I feel guilty about my approach, but it has worked and made for fast development so far without any serious production problems:

I basically build and test everything on a paper account against live data and debug from there. Whenever I run it in production so far I have monitored it and occasionally found minor bugs, but nothing that caused me to lose money. This is enabled me to get to production more quickly I think, and over time I have found a lot of corner case weird production bugs that I would never have caught probably with some sort of test suite that emulates IB.?

On Sat, Feb 20, 2021, 12:27 PM Jonathan S <jsheena@...> wrote:
My CI testing follows what Mark outlines.??
My code is in Java.? I wrote a broker interface which limits the IB API pieces I use.? I then use a mock class framework (Mockito) to simulate responses.? This of course doesn't simulate TWS, but at least allows for testing of my code.

But sometimes weird things happen in production and TWS doesn't do what you expect, so an idea I had was to implement a TWS API "recorder" so I can record/replay IB API events to diagnose problems that come up in production.? Then use those event records to generate test cases.
Matthias Frener
 

Thanks for all the answers so far :)
A simular or any kind of moch is pretty much out of question.
We are build an API client (the API interface and encoder/decoder to process the messages that go to / come from the TCP socket).
The background of this exercise is ensure that out lib works across kind of different TWS versions, ideal on CI, firing up 20 dockers in parallel.
(the root issue the account - we need out paper accounts for local testing, was hoping for some dev-program form IB or a reference server, or idk... =) )

1 - 6 of 6