There are a number of untested functions in doltpy.core that were introduced to in 1.0.0 to match the CLI. A list of them is:
reset: no testing, hard and soft modes need to be tested
diff: no explicit testing, not used in testing, currently just prints output, we may want to rethink this to use some kind of objects or bind it to queryable diffs and populate the diff in a DataFrame type structure
blame: no explicit testing, not used in testing, currently just prints output, like diff might benefit from being stored in a programmatically accessible data structure
push: not tested, and actually missing a host of more escoteric options that exist in the CLI
pull: same as push
fetch: same as push and pull
clone: again, untested
creds_*: untested
config: untested
schema_*: no testing, and not clear what the interface should be given that it can do a number of things
table_*: no testing, and not clear what the interface should be given it can a number of things
Incomplete testing:
commit: used in testing but date and allow_empty not tested
sql: basic query execution is tested but non the others modes (result_format, etc.)
sql_server: most basic execution of query tested but not other modes
branch: basic branch creation is tested, but force, start_point etc., are not.
checkout: used in basic testing of branch, but start_point not tested
ls: no testing of system and all switches
Others that are used in tests but not explicitly tested:
init: no explicit tests but relied on by other tests
add: no explicit testing, but used everywhere in tests
I think we can just reference use this ticket to hash out a plan for testing (what needs to be tested and the priorities) and interface design, as there are few functions that would benefit from a programmatic interface, not just printing a string.
There are a number of untested functions in
doltpy.corethat were introduced to in 1.0.0 to match the CLI. A list of them is:reset: no testing,hardandsoftmodes need to be testeddiff: no explicit testing, not used in testing, currently just prints output, we may want to rethink this to use some kind of objects or bind it to queryable diffs and populate the diff in a DataFrame type structureblame: no explicit testing, not used in testing, currently just prints output, likediffmight benefit from being stored in a programmatically accessible data structurepush: not tested, and actually missing a host of more escoteric options that exist in the CLIpull: same aspushfetch: same aspushandpullclone: again, untestedcreds_*: untestedconfig: untestedschema_*: no testing, and not clear what the interface should be given that it can do a number of thingstable_*: no testing, and not clear what the interface should be given it can a number of thingsIncomplete testing:
commit: used in testing butdateandallow_emptynot testedsql: basic query execution is tested but non the others modes (result_format, etc.)sql_server: most basic execution of query tested but not other modesbranch: basic branch creation is tested, butforce,start_pointetc., are not.checkout: used in basic testing ofbranch, butstart_pointnot testedls: no testing ofsystemandallswitchesOthers that are used in tests but not explicitly tested:
init: no explicit tests but relied on by other testsadd: no explicit testing, but used everywhere in testsI think we can just reference use this ticket to hash out a plan for testing (what needs to be tested and the priorities) and interface design, as there are few functions that would benefit from a programmatic interface, not just printing a string.