Issue 10 pytest

[kan-fu]

Fix #10 Completely replaced robot framework with pytest. Most of the test cases use the params from the OpenAPI page examples. I deleted some tests that just used different params for the same web service (for example multiple getLocations tests with locationCode, locationName, deviceCategoryCode,...), as the client library simply passes the params to the request, so those tests won't increase the test coverage. They should be in the internal test framework for the backend. I also dropped support for Python 3.8, which is agreed by Spencer after we fixed the Python version issue on the task machine (previous disccusion). It should be in a new issue, but I used a dictionary union operator in the tests, which is a new feature in Python 3.9.

[kan-fu]

Way to go moving all this from robots! Now that it's easier to read the tests, I have two thoughts. None of these should be seen as blocking - the PR is an improvement on the state of the code as-is, so you should feel comfortable merging it as-is rather than dragging out the review/edit process. Nevertheless, you might still want to consider them before checking off whatever internal ticketing system you have:

1. This test code seems very nested, with 50 files of 10-50 lines. This means a lot of repeated code across files. When code is flattened and similar code is next to each other, the repetition becomes more obvious and important differences stand out: e.g. scalar_data.test_scalardata_device.test_no_data vs scalar_data.test_scalardata_location.test_no_data behave very differently, even though they're called in the same way: One returns an HTTP error, the other an object with an empty container. That they can be called the same way but behave differently suggests that perhaps the ONC API might be confusing for users and could be fixed - but the comparison is only clear when repetition is removed and code is flattened.

More simply, there's no need for folders with only one file, e.g. discover_properties/test_properties.py could just be test_properties.py. The other folders with multiple files (archive_file, data_product_delivery) probably could also be combined to both shorten the overall SLOC and make it clearer.

2. Runtime. Have you checked the durations of individual tests (pytest --durations=100)? Consider:

Test durations The longest test runs for >60 sec, around 20% of the runtime. The top ten tests account for over 80%. This obviously depends upon the behavior of the server, and maybe QA is faster. If so, it might make sense to mark these tests as slow and only call them in CI. Or if QA is much faster, to allow CI (and maybe me?) to use the QA server.

Regardless, ordering data products seems to be responsible for most of the runtime. Maybe this indicates that, as a higher-level function, it doesn't deserve four different tests for parameter combinations, and instead vary the parameters on lower level (requesting, running, and downloading) functionality? Or maybe the ordered data products are too large/complex for the server? Thanks for your detail comment!

1. My initial motivation for this nested test directory structure is that everything mirrors the same structure in the OpenAPI page, so that I (and also the Matlab library maintainer) don't need to make decisions. Using various packages in Java also seems natural to me. But I agree that "flat is better than nested" based on the zen of python. I will have a new ticket (already got some commits based on this branch) for improving the structure of the tests directory:
   • All the discover tests can be extracted out to get rid of their parent folder.
   • The scalardata, rawdata and archivefile contains tests that are quite similar (by location and by device). Combining them will definitely help reduce code duplicate and feature comparison (like no_data test). I also have a plan to add a helper method to combine them together in v3.0.0, like get_scalardata that delegates the params to get_scarlardata_by_device and get_scarlardata_by_location based on whether the params include a "deviceCode" key. Testing them in one file (possibly with parameterized tests) makes sense.
   • For data product delivery and other tests in archive file (like download and direct download), I prefer keeping the folder. I think combining is not that valuable in terms of feature comparison since the tested methods are quite different. Also after my pr for #26, data product delivery would have tests for another three api end points. Merging them together might make the file hard to read.
2. Unfortunately QA does not make it faster. Data product delivery system is slow in nature. The slowest test took me 63 seconds to finish in QA. The two main reasons for me to use QA is to test new features in QA and not burden the PROD server & database. I think it is a good idea to mark the whole data product delivery valid tests as slow and only enable them in GitHub Actions.

For the lower-level (requesting, running, and downloading) and higher-level (order) functions of data product delivery, I have to say the code is not that intuitive to me. I initially thought orderDataProduct is just the combination of the three methods, like what I did in the test_valid_manual, but the code did something more complex. Maybe this method needs some code refactor first.