Type: Bug (missing test coverage)
Area: WinGetSourceCreator, IndexCreationTool
There is good coverage for the low-level index API, but not for the layer above
it that actually assembles a source.
WinGetUtilSQLiteIndex.cs (src/AppInstallerCLIE2ETests/WinGetUtil/) already
tests the WinGetUtil SQLite index directly - add/update/remove manifest,
open/close, PrepareForPackaging + consistency check. That coverage is solid,
but it feeds a single pre-merged manifest file straight into the index API.
What isn't covered is the WinGetSourceCreator / IndexCreationTool layer that
sits on top of it - the part that discovers manifests, copies them into the
working directory, handles multi-file manifests, and drives the index build.
Today that layer is only run as unverified test setup:
TestIndex.GenerateE2ESource() (src/AppInstallerCLIE2ETests/Helpers/TestIndex.cs)
calls WinGetLocalSource.CreateLocalSource(...).- It runs from
[OneTimeSetUp] in src/AppInstallerCLIE2ETests/SetUpFixture.cs
to build the source that other tests search against, so it isn't itself a test
of the source-creation path and the produced index isn't verified.
- The manifests it uses are all singleton, so the multi-file layout never goes
through this path.
Because nothing exercises this layer directly, regressions in it can go
unnoticed for a long time. Two examples:
Request
Could we add an E2E test for the WinGetSourceCreator / IndexCreationTool
path that builds a source from both a singleton and a multi-file manifest and
asserts the expected packages end up in the resulting index? This complements
the existing WinGetUtilSQLiteIndex tests rather than duplicating them.
We'd be glad to open a PR with this test if a maintainer is willing to review it.
Type: Bug (missing test coverage)
Area:
WinGetSourceCreator,IndexCreationToolThere is good coverage for the low-level index API, but not for the layer above
it that actually assembles a source.
WinGetUtilSQLiteIndex.cs(src/AppInstallerCLIE2ETests/WinGetUtil/) alreadytests the
WinGetUtilSQLite index directly - add/update/remove manifest,open/close,
PrepareForPackaging+ consistency check. That coverage is solid,but it feeds a single pre-merged manifest file straight into the index API.
What isn't covered is the
WinGetSourceCreator/IndexCreationToollayer thatsits on top of it - the part that discovers manifests, copies them into the
working directory, handles multi-file manifests, and drives the index build.
Today that layer is only run as unverified test setup:
TestIndex.GenerateE2ESource()(src/AppInstallerCLIE2ETests/Helpers/TestIndex.cs)calls
WinGetLocalSource.CreateLocalSource(...).[OneTimeSetUp]insrc/AppInstallerCLIE2ETests/SetUpFixture.csto build the source that other tests search against, so it isn't itself a test
of the source-creation path and the produced index isn't verified.
through this path.
Because nothing exercises this layer directly, regressions in it can go
unnoticed for a long time. Two examples:
that isn't there; open for ~2 years.
Request
Could we add an E2E test for the
WinGetSourceCreator/IndexCreationToolpath that builds a source from both a singleton and a multi-file manifest and
asserts the expected packages end up in the resulting index? This complements
the existing
WinGetUtilSQLiteIndextests rather than duplicating them.We'd be glad to open a PR with this test if a maintainer is willing to review it.