Get code coverage to 100%
Created by: Zach DeCook
Since #2 (closed) is done, we should strive for 100% code coverage before attempting #1 (closed). Progress
We should do this in the following ways:
- unit tests: mock the output of external programs, and test smaller bits of code (should be tested with multiple versions of python)
- feature tests: install dependencies in testing containers and test the system as a whole (we can use the
--cov-appendflag inpytest-covto aggregate coverage reports passed from different pipeline stages) - Ignore lines that will be deprecated in future versions (
#pragma: no covercomments incoverage). We only need to make sure to test the lines that we care about supporting in the future.
Imported comments:
By Silas S. Brown on 2019-11-21T10:28:07.238Z
closed via commit ead21428
By Zach DeCook on 2019-10-05T15:43:08.496Z
mentioned in merge request !2
By Silas S. Brown on 2019-10-03T10:10:33.837Z
Well class MacBritish_System_Lexicon can only really be tested on a Mac (and only on certain specific versions of MacOS and where it's been given permission to write to certain system files), so the chances of getting that part auto-tested by GitLab are remote. But I'd be happy to drop that functionality from the Python 3 version if the Python 2 version will still be around: after all, the old Macs where this code is useful all came with Python 2 interpreters.
Less 'clear-cut' is parse_festival_dict depending on the festlex-oald package which is in Debian's "non-free" section because it disallows commercial use. We can't import it into our project if we're GPL, so we'd either depend on GitLab being able to download non-free stuff (I haven't looked into this), or we mock it, or we drop that functionality too which would be more of a pity because I do expect some Python 3 users might want to import OALD on their systems for personal use and I do still think we should enable that if we can.
By Zach DeCook on 2019-10-03T04:26:48.810Z
mentioned in issue #4