Coding 2022-04-25
No thread again. I focused on writing up all of the cases missing for coverage, and my notes ended up something like:
Misc:
- Missing branch in plugin code
- pytest.testdir_builder (just write a test)
- package.combine_packages (empty, and multiple)
- pip.package (leading dash)
- pip.python_version_string (absolute path, multi-part path, valid input)
- dynamic.inject normal and error case
- dynamic.reduce
Validators:
- input_accumulator.accumulator decorator
- installer.PathWith
- not_output cases for:
- Output
- CmdMeta with env
- CmdMeta with extra io
- Command
- dynamic.DynamicMeta
Methods:
- python_helpers.PythonCmd.add_sub_cmds
- arguments.Option.with_option
- arguments.Command.with_module success case
- arguments.Command.with_module failure case
- validators.RejectBecause.__repr__
- (Corresponding __call__ should be handled by other cases for now)
- invocation.Argument.build (with and without prefix)
- invocation.EnvVar.build
- invocation.Invocation.invoke (module non-None, and another with adaptor conflicts)
- flex.ExtraParent.map
- flex.Argparent.map (prefix is None)
- flex.FlexIn.convert
- flex.FlexIn.metadata
- flex.FlexIn.forbid_narrowing
- flex.FlexOut.convert (make_parent is None)
- flex.FlexOut.metadata
- flex.FlexOut.forbid_narrowing
- pip.VirtualenvArgs.setup_environment (with python version string)
- pip.PipArgs.arguments (with Constraint, with Requirement)
- command.CmdMeta.resolve_* with Module arguments and sometimes str arguments
- command.base_cmd
- build.Build.__call__ in various configurations
- dynamic.DynamicMeta.not_accumulable_because (used as validator elsewhere)
- dynamic.DynamicMeta.not_flex_out_because (used as validator elsewhere)
- dynamic.DynamicMeta.with_flex error case
- dynamic.DynamicMeta.narrow_labels normal and error case
- dynamic.DynamicMeta.combine same and different value
- dynamic.DynamicMeta.iter_labels normal and error case
Decorators:
- python_helpers.requirement_invocation
For now, some of this overlaps, but in any case, getting the 8% or so (116 statements) coverage this all represents is clearly going to be A Thing, and I'm going to have to take more notes to figure out what the tests for these are going to look like, and therefore what kind of tests I should be writing.
Ugh, I just compared the flake8 tests to the current motrfile. I really hope the approach I'm pursuing currently pays serious dividends when it comes to invoking pytest, because on the flake8 side of things, it's breaking even at best. Like, what if the biggest saving here just comes from no longer defining package and builder concepts in the motrfile? To be clear, that would still be a major win, but I really want to see something more dramatic out of this effort.
Anyway, it won't do to stress out over this. I need to relax and take a break from staring at my screen.
Good night.