search

Petersoj / alpaca-java

A Java API for Alpaca, the commission free, algo friendly, stock trading broker. https://alpaca.markets
https://petersoj.github.io/alpaca-java/
MIT License
197 stars 82 forks source link

Unit Testing + Coverage Setup #31

Closed mainstringargs closed 3 years ago

mainstringargs commented 4 years ago

Add Unit Testing + Mocking libraries to Gradle configuration Add Unit Testing + Coverage output to CI configuration Make results available on github

Petersoj commented 4 years ago

@mainstringargs After noticing several Polygon endpoint changes and thereby breaking part of this Java API, I realized that unit testing should be worked on. As far as testing goes for this entire project though, I think it would be best to use a combination of a Mocking library, but also use real endpoints to test Polygon and Alpaca to validate that all received JSON has been populated accordingly into the schema POJOs. This would require an API key that is associated with a live account, as well as the market being open for certain tests (and if it's not, then the tests are skipped perhaps). For the CI, you can use encrypted variables to load API keys or we can just prevent the CI from doing unit tests and require that unit tests are done on our own machines with the market being open using our own API keys. I think that this will allow us to keep this API up-to-date better instead of using Mockito so we can reflect the real endpoints/doc changes in this API. What do you think?

mainstringargs commented 4 years ago

Yeah, I completely agree and really like your idea of using live endpoints. That is really the only way to 'guarantee' we're API compliant, because if we just mock everything out its impossible to know what breaks until things go live. I've been meaning to work on this for quite a while, but life and work keep getting in the way.

I'm thinking at least initially, just having a flag or logic to not run the 'live endpoints' tests under CI may suffice? I'm a bit nervous about using either of our API keys / secrets to test with (even with encryption and especially with the AlpacaAPI portion) -- but then again, if its just a "Paper" key/secret, then maybe we're safe.

Petersoj commented 4 years ago

Yeah for the CI, it would probably be best to not use any API keys even under an encrypted setting, even if it's just a Paper API key. Although TravisCI does a good job at masking secure variables in the build log, it's better to be safer here. So full unit testing on our own machines would require an open market and available paper/live API keys, but if this environment is not available (like in the CI build), then it would just use Mockito where necessary/available. I totally understand the time constraint. I've got a few other projects I'm working on right now and I have school, but I'll make a draft PR in the next few weeks to get started on this 👍

Petersoj commented 3 years ago

Initial unit tests have been added (both live and mocked) in 7.0 and more will be added :)