write exactly one meaningful failing test for a c# or .net codebase based on a requirement, acceptance criterion, bug report, or existing code analysis. use when the task is to start the red step of tdd, prove that a feature does not yet exist, reproduce a bug with a test, or choose the smallest next failing behavior. keep tests concise, readable, and specialized; create helpers only when they reduce setup noise; never fake failure with unconditional assertions; never change production code; and hand off execution to dotnet-test or dotnet-test-mtp. do not use for implementing the fix, broad refactors, or writing multiple new tests at once.
Write one failing test that fails for the right reason.
Assert.True(false), Assert.Fail(), throwing manually, or any equivalent fake failure.Prefer these failure modes in order:
A compile-time red test is acceptable when the absence of a type, method, property, or overload is the clearest proof that the feature does not yet exist. Do not use compile-time failure as a shortcut when a runtime behavior test is possible.
Before producing the test:
Produce the response in this shape:
One sentence describing the exact missing behavior or bug manifestation.
Provide only the new or changed test code and any tiny helper needed for readability.
Explain the exact reason this test should fail today.
State the narrowest test scope that should be run through dotnet-test or dotnet-test-mtp.
Stop and wait for review. Do not propose a fix unless the user asks to proceed to green.