With #2993 a container's setup comes from every Pester.BeforeContainer.ps1 between Run.RepoRoot and the test file's own folder, and #pester:no-inherit can cut that chain short. Nothing in the result says which files were used.
That makes "where did this function come from" unanswerable from the outside. Opening tests/unit/Foo.Tests.ps1 shows no BeforeAll, and gives no signal that two folder setups ran before it. Reading the directory tree is not enough either, because #pester:no-inherit can truncate the chain.
Suggestion
Expose the applied setup files on the container, not the block. It is a property of the file being run, post-processors already walk containers, and it keeps the block model unchanged.
Pester resolves the chain per container in the parent already (Resolve-PesterBeforeContainerMap), so the value exists at the point the container is created.
Related
With #2993 a container's setup comes from every
Pester.BeforeContainer.ps1betweenRun.RepoRootand the test file's own folder, and#pester:no-inheritcan cut that chain short. Nothing in the result says which files were used.That makes "where did this function come from" unanswerable from the outside. Opening
tests/unit/Foo.Tests.ps1shows noBeforeAll, and gives no signal that two folder setups ran before it. Reading the directory tree is not enough either, because#pester:no-inheritcan truncate the chain.Suggestion
Expose the applied setup files on the container, not the block. It is a property of the file being run, post-processors already walk containers, and it keeps the block model unchanged.
Pester resolves the chain per container in the parent already (
Resolve-PesterBeforeContainerMap), so the value exists at the point the container is created.Related
#pester:no-inherittruncates a chain, but only underDebug.WriteDebugMessages