Closed ParthS007 closed 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.
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
.
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 totests/test_tui.py
file. You can emulatetest_validator.py
that contain tests forvalidator.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
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?
@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
.
closes #22