Open johnthcall opened 2 years ago
Fixed by #1154
Fixed by #1172
Hey @johnthcall, thanks! And sorry for the typo :)
Reopening the issue as changes are reverted. Long story short we misidentified the impact and as it is introducing some breaking changes we will postpone its fix in v4 of MSTest.
Just to confirm, is [CallerArgumentExpression]
not supported at all currently by MSTest? Meaning no methods using the attribute would be able to be unit tested using MSTest?
If your method has some argument marked with the CallerArgumentExpression
attribute there is no problem for the method to be tested. The goal of this ticket is to rewrite MSTest assertions methods to be using this attribute so that if the user provides no custom message we can provide a better default message (being the caller expression).
Ahh I see, thanks for the clarification
I think this can be achieved by creating extension methods on the Assert
class.
usage would be something like:
[TestMethod]
public void Test()
{
object subject = ...;
Assert.That.IsNotNull(subject);
}
// extension:
public static class AssertExtensions
{
public static void IsNotNull(this Assert assert, object subject,
[CallerArgumentExpression(nameof(subject))] string actualExpression = "")
{
var message ??= $"Expected {actualExpression} to not be null.";
Assert.IsNotNull(subject, message);
}
}
Description
With .Net 6 Caller Argument Expression was added, this could be used in testfx to provide the expression which failed the check. Doing this could provider consumers more out of the box detail about what caused the assert to fail without having to manually provide messages.
Sample Code change
Work required
Assert.IsNull(myParam)
execute passingmyParam
as the message.Change in behavior
Currently a failing call to Assert.IsNull without a message will just return
Assert.IsNull failed.
This would change toAssert.IsNull failed. myParam
which could be considered a breaking change and a result a no-go.AB#1588958