'Unit Tests' / Cloud-API Integration Tests

[ObjectIsAdvantag]

Goal here is to provide a directory with unit test for Spark API calls supported by the library.

[cmlccie]

Completely agreed. It's on the backlog. Care to write or contribute to these?

[ObjectIsAdvantag]

Would love but I am not very versed on python.
It is much easier for me to review python code than write some.

[cmlccie]

Rather than attempting to write a complicated set of offline unit tests, we should rather just create a complete set or sequence of Cloud-API Integration Tests. In other words, create a sequence of API calls where every method (API call) is made with every available option (argument), and verify the expected results.

[tonybaloney]

I'd start with a set of recorded responses from a live API first then build the tests around those.
I'm working on a package that does this which support this libraries way of using requests sessions.
https://pypi.python.org/pypi/requests-staticmock/0.5.0
Will see if anyone is able to contribute here

[cmlccie]

@tonybaloney That's a fantastic idea.

I am currently creating the full test suite for the package using py.test. I have thought that I could create a mock in between the package and the requests module that could proxy and record all of the API calls and responses, and (once cached) could use the saved the responses for repeated test runs. This would at least ensure the packages functionality (down to the calls to the requests package).

If you are already mocking this up, I would be glad to test out and leverage your solution.

[tonybaloney]

@cmlccie I've just finished doing exactly that for another project
https://github.com/tonybaloney/pluralsight/tree/master/tests
We can reuse some of the patterns

[cmlccie]

The on-line test suite is complete, though I'm not sure that the calls could easily be made into offline tests. With the interactive and dependent nature of the API calls (some objects must be created before others, some items must be deleted and confirmed to have been deleted), this may be a significant challenge.

I was able to use the awesome py.test fixtures to model these interdependencies in such a way that API calls are minimized and sequenced while still maintaining the relative atomic states of the individual tests.