Page MenuHomeSoftware Heritage

graph service: add tests for the python client
Closed, MigratedEdits Locked

Description

$ ./setup.py test
----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

Event Timeline

zack triaged this task as Normal priority.Jul 18 2019, 4:27 PM
zack created this task.

What kind of tests do we want for the client side code? Checking the resulting json format for each endpoints?

We want to test that the client part of a complete client<->server interaction works properly. The best way to do that is, in fact, to rerun the same tests we run on the server side, but via the Python client. If there is an easy way to just reuse the same test code (e.g., by generating Python tests from the Java ones, or vice-versa), go for it. But probably it isn't worth it, as there isn't much test code anyway. If there is no way to keep parity, we should go for something minimal on the Python side, e.g., just test one call per API endpoint, and keep a more complete coverage on the Java side (again: or vice-versa, if we prefer to maintain the Python test code base than the Java one).

Either way, note that the Python testsuite will need to start the Java server upon setup and shut it down upon teardown.

One test call per endpoint seems enough right now, the Python side relies entirely on swh custom REST API class for client <-> server interaction (which has tests on its own).

In the long run, the tests will go where the core logic code is, and with Python bindings this means in the Python side.