Summary
MoveToFolderAsync_WhenArchiveRootResolves_StillReadsItOnce terminates its success path on a
NullReferenceException raised by the EmailFiler collaborator rather than on a deliberate stopping
point. The test is correct today, but its failure message would misdirect a future maintainer if
EmailFiler.SortAsync ever gains a null guard.
Environment
- OS/version: Windows 11, .NET Framework 4.8.1
- Python version: not applicable; this is an MSTest C# unit test
- Command/flags used:
vstest.console.exe QuickFiler.Test\bin\Debug\QuickFiler.Test.dll /TestCaseFilter:"FullyQualifiedName~EfcDataModelArchiveRootTests"
- Data source or fixture:
TestableEfcDataModel with a strict Mock<IOlObjects> and a parameterless MailItemHelper
Steps to Reproduce
- Add a null guard to
EmailFiler.SortAsync so it returns false instead of dereferencing a null FolderInfo.
- Re-run
MoveToFolderAsync_WhenArchiveRootResolves_StillReadsItOnce.
Expected Behavior
The test terminates the success path deliberately and asserts only the invariant it exists to pin,
which is olObjects.VerifyGet(value => value.ArchiveRootPath, Times.Once()). A failure reports a
problem with the archive-root read count.
Actual Behavior
The test asserts await act.Should().ThrowAsync<NullReferenceException>() before the VerifyGet. That
exception is not a property of the unit under test: it is the EmailFiler collaborator dereferencing
a MailItemHelper whose folder information is null, several frames past the code issue 638 touched.
Once EmailFiler no longer throws there, the test fails with a message about a missing
NullReferenceException and points at the wrong subsystem.
Logs / Screenshots
Impact / Severity
Source
From: docs/features/potential/2026-08-29-efcdatamodel-success-path-test-uses-incidental-crash-as-barrier.md
Summary
MoveToFolderAsync_WhenArchiveRootResolves_StillReadsItOnceterminates its success path on aNullReferenceExceptionraised by theEmailFilercollaborator rather than on a deliberate stoppingpoint. The test is correct today, but its failure message would misdirect a future maintainer if
EmailFiler.SortAsyncever gains a null guard.Environment
vstest.console.exe QuickFiler.Test\bin\Debug\QuickFiler.Test.dll /TestCaseFilter:"FullyQualifiedName~EfcDataModelArchiveRootTests"TestableEfcDataModelwith a strictMock<IOlObjects>and a parameterlessMailItemHelperSteps to Reproduce
EmailFiler.SortAsyncso it returnsfalseinstead of dereferencing a nullFolderInfo.MoveToFolderAsync_WhenArchiveRootResolves_StillReadsItOnce.Expected Behavior
The test terminates the success path deliberately and asserts only the invariant it exists to pin,
which is
olObjects.VerifyGet(value => value.ArchiveRootPath, Times.Once()). A failure reports aproblem with the archive-root read count.
Actual Behavior
The test asserts
await act.Should().ThrowAsync<NullReferenceException>()before theVerifyGet. Thatexception is not a property of the unit under test: it is the
EmailFilercollaborator dereferencinga
MailItemHelperwhose folder information is null, several frames past the code issue 638 touched.Once
EmailFilerno longer throws there, the test fails with a message about a missingNullReferenceExceptionand points at the wrong subsystem.Logs / Screenshots
Impact / Severity
Source
From: docs/features/potential/2026-08-29-efcdatamodel-success-path-test-uses-incidental-crash-as-barrier.md