Repository navigation
Clean up 14 nullable warnings in CodeShellManager.UITests so the solution build is honestly zero #92
Description
Found during the v0.6.0 pre-release review. Purely hygiene, but it costs real signal.
Current state
After #86 and #89, the app and unit-test projects build at 0 warnings. The UI test project does not:
| Warning | Count | Meaning |
|---|---|---|
CS8602 |
22 | Dereference of a possibly null reference |
CS8618 |
2 | Non-nullable property not initialised in constructor |
CS8603 |
2 | Possible null reference return |
CS8601 |
2 | Possible null reference assignment |
Concentrated in three files:
AppActions.cs— 16SettingsTests.cs— 8AppFixture.cs— 4
Why bother
A full solution build reports these every time, so a genuinely new warning in the app has to be spotted among them. That's exactly what happened with the 15 CS8123 warnings fixed in #86 — they were noise that made the real NU1903 advisory easy to skim past.
Notes for whoever picks this up
These are almost all FlaUI element lookups (FindFirstDescendant(...) returning AutomationElement? and being dereferenced immediately). The honest fix is usually an assertion rather than a !:
var btn = window.FindFirstDescendant(cf => cf.ByAutomationId("NewSession"));
Assert.NotNull(btn); // fails the test with a useful message
btn!.Click();Using ! everywhere would silence the warnings while turning a missing-element bug into a NullReferenceException with no context — worse than the warning. Prefer assertions at the lookup site.
Deliberately not done before the v0.6.0 tag: FlaUI tests need a live Windows desktop to verify, and churning them immediately before a release adds risk without adding confidence.
Activity
AThraen commentedon Sep 6, 2026
Recount: it's 14 warnings, not 28
Rebuilt
tests/CodeShellManager.UITestsagainst currentmain. The build reports 14 warnings, and the table in this issue is exactly double every figure in it — MSBuild prints each warning twice (once inline, once in the summary block), and the original count was taken off the raw output.Nothing has been fixed here; the work is the same size, just half as large as advertised.
Current state
CS8602(dereference of a possibly null reference)CS8618(non-nullable property not initialised)CS8603(possible null reference return)CS8601(possible null reference assignment)By file — 14 sites total:
Helpers/AppActions.cs(8) — lines 26, 53, 58, 61, 114, 120, 125, 128SettingsTests.cs(4) — lines 37, 40, 60, 63AppFixture.cs(2) — lines 22, 33The guidance in the issue body still stands: these are FlaUI
FindFirstDescendant(...)lookups returningAutomationElement?and being dereferenced immediately, and the honest fix isAssert.NotNullat the lookup site rather than!, so a missing element fails the test with a useful message instead of throwing a context-freeNullReferenceException.The rationale for doing it also still stands: the app and unit-test projects build at 0 warnings, so these 14 are the only thing between a solution build and honest zero.
[-]Clean up 28 nullable warnings in CodeShellManager.UITests so the solution build is honestly zero[/-][+]Clean up 14 nullable warnings in CodeShellManager.UITests so the solution build is honestly zero[/+]fix: v0.8.0 pre-release hardening — command injection, UI-thread spaw…