The logic of Core, SPMGraphLint, SPMGraphTests, SPMGraphVisualize, and SPMGraphConfigSetup is not unit-tested.
Only E2E tests cover them, while the SPMGraphConfigInterface module is the only unit-tested.
The main reason is that most of those depend on loading a Swift Package, which is tightly coupled with the spm lib. Tests can be written, but they require initializing a fixture package, given that the Package model doesn't have simpler test-only factory/init methods.
Options
A
Write tests by loading the existing or new fixture packages within the FixtureSupport module - as is done for the SPMGraphConfigInterfaceTests. The downside is that the only way to load such packages is to use the concrete/production logic for loading a package via the SPM lib, which makes those tests less deterministic and not really unit tests.
B
Wait for #32. By moving to PIF, we might be able to create our own dumb/pure package/graph model and make testing easier.
The logic of
Core,SPMGraphLint,SPMGraphTests,SPMGraphVisualize, andSPMGraphConfigSetupis not unit-tested.Only E2E tests cover them, while the
SPMGraphConfigInterfacemodule is the only unit-tested.The main reason is that most of those depend on loading a Swift Package, which is tightly coupled with the
spmlib. Tests can be written, but they require initializing a fixture package, given that thePackagemodel doesn't have simpler test-only factory/init methods.Options
A
Write tests by loading the existing or new fixture packages within the
FixtureSupportmodule - as is done for theSPMGraphConfigInterfaceTests. The downside is that the only way to load such packages is to use the concrete/production logic for loading a package via the SPM lib, which makes those tests less deterministic and not really unit tests.B
Wait for #32. By moving to PIF, we might be able to create our own dumb/pure package/graph model and make testing easier.