Instructions for updating VerifyDiagnostics and VerifyIL expectations in tests#83067
Instructions for updating VerifyDiagnostics and VerifyIL expectations in tests#83067jcouv merged 1 commit intodotnet:mainfrom
Conversation
| - **Unit tests**: Test individual compiler phases (lexing, parsing) | ||
| - **Compilation tests**: Create `Compilation` objects and verify symbols/diagnostics | ||
| - **Cross-language patterns**: Many test patterns work for both C# and VB with minor syntax changes | ||
| - **Verification baselines**: When helpers like `VerifyDiagnostics`, `VerifyEmitDiagnostics`, `VerifyIL`, and similar compiler test APIs fail with an `Actual:` block containing the expected test content, copy that block directly into the verification call. |
There was a problem hiding this comment.
Do comments like "align with existing baseline texts" help? Should we make this a standalone skill?
There was a problem hiding this comment.
I tried adding that sentence to instructions, but I didn't notice a difference.
The main problem I was trying to solve was the model putting stuff like:
CreateCompilation(source, options: TestOptions.UnsafeDebugExe).VerifyDiagnostics(
Diagnostic(ErrorCode.WRN_AddressOfInAsync, "localFuncLocal").WithLocation(32, 39));
With the instructions, it correctly copied the comments in a few cases that I tried, so I'm happy.
FWIW, asked the model to reflect on that and it concurred :-P (copied below).
I'm wondering whether including "align with existing baseline texts" in the instructions for `VerifyDiagnostics` was helpful. What do you think?
● Looking at how I solved this — I ran the test, copied the Actual: block from the failure output directly into the VerifyDiagnostics call. That's exactly the standard workflow documented in the repo's custom instructions ("copy that block directly into the verification call").
I didn't need any "align with existing baseline texts" guidance to do that. The existing instruction about copying the Actual: block was sufficient. An extra instruction about aligning with baseline texts could actually be counterproductive — it might encourage trying to
manually massage the expected output rather than just trusting the compiler's actual output.
So no, I don't think it added value here. The simpler, existing guidance was enough.
As for skill, maybe at some point. The advantage of a skill is that we could go into more details, include examples and such, without cluttering the context window by default. But so far, I found this one line instruction to be effective, so seems fine as first step.
Microsoft Reviewers: Open in CodeFlow