cernopendata / cernopendata-client

CERN Open Data command-line client
http://cernopendata-client.readthedocs.io/
GNU General Public License v3.0
10 stars 9 forks source link

cli: download files feature #34

Closed ParthS007 closed 4 years ago

ParthS007 commented 4 years ago

closes #22

ParthS007 commented 4 years ago

@tiborsimko I can write the test for testing the download helper in tui.py now. Please provide me the location of the file we discussed in person.

tiborsimko commented 4 years ago

I can write the test for testing the download helper in tui.py now. Please provide me the location of the file we discussed in person.

Good then! The tests for tui.py should go to tests/test_tui.py file. You can emulate test_validator.py that contain tests for validator.py.

tiborsimko commented 4 years ago

I can write the test for testing the download helper in tui.py now. Please provide me the location of the file we discussed in person.

Good then! The tests for tui.py should go to tests/test_tui.py file. You can emulate test_validator.py that contain tests for validator.py.

We were testing http://opendata.cern.ch/record/1050/files/2010RunBlumi.txt but record 1050 has three files; let's perhaps use another record which has only one file? Example: http://opendata.cern.ch/record/3005/files/0d0714743f0204ed3c0144941e6ce248.configFile.py

ParthS007 commented 4 years ago

Testing one file seems fine to me for now, once I implement a low-level download_function, then we can add other test cases as well. what do you think?

ParthS007 commented 4 years ago

@tiborsimko I added basic tests for testing CLI commands and since we are not calling directly show_download_progress, I thought of writing a test for download-files command instead of show_download_progress. By doing this, we have coverage for both functions.

Is this the right way to approach this?

Please let me know, I will do the changes if required.

For get_record and get_file_locations, I added basic tests for checking the output type on the basis of recid.