8

I do not want to disable the warnings completely, just when it's in an Assert statement.

So for example if I have the following two lines

var someObject = GetObject();
Assert.IsNotNull(someObject, "someObject should not be null");
Assert.AreEqual(expectedValue, someObject.SomeProperty);

I'll get the possible null reference warning on the second line on someObject.SomeProperty. Is it possible to disable the warning when it is within a certain call, like Assert.AreEqual?

Since this is an issue with a lot of unit tests, I don't want to litter the tests with the ReSharper disable code.

Right now the only option I can think of is to change every Assert.IsNotNull call to be

var someObject = GetObject();
if(someObject == null)
{
  Assert.Fail("someObject is null");
  return;
}

Although this kind of seems to defeat the purpose of having Assert.IsNotNull in the first place. Just wondering if there is a better way.

Brandon
  • 68,708
  • 30
  • 194
  • 223
  • Related: http://stackoverflow.com/questions/4393456/resharper-how-to-remove-possible-system-nullreferenceexception-warning – JYelton Mar 23 '12 at 15:30
  • Can you post a fuller example? I cannot reproduce this; when using NUnit's assertion library the addition of Assert.IsNotNull removes the warning - and whether it is in a test or not has no effect. – James World Mar 23 '12 at 15:47
  • @JamesWorld, I'm using MBUnit, not sure if that makes a difference. The code I posted does give the warning using MBUnit 2.4.2 and ReSharper 6.1. I know it doesn't matter if it's in a test or not, but I'm only concerned with disabling it in test classes. Everywhere else it should be enabled. – Brandon Mar 23 '12 at 15:52
  • Yes I spotted the use of MBUnit, that's why I called out I was using NUnit. I switch my test to MBUnit and see that is doesn't remove the warning. The problem must lie in differences in their implementation. – James World Mar 23 '12 at 15:56

6 Answers6

1

Add this to your project:

public static class AssertionsExtensions
{
    [NotNull]
    public static TSubject ShouldNotBeNull<TSubject>([CanBeNull] this TSubject source,
        [CanBeNull] string because = "", [CanBeNull] [ItemCanBeNull] params object[] reasonArgs)
    {
        source.Should().NotBeNull(because, reasonArgs);

        // ReSharper disable once AssignNullToNotNullAttribute
        return source;
    }
}

Then use it like this, for example:

            // Assert
            succeeded.Should().Be(true, "<USB loopback cable must be connected and COM port must be correct.>");
            DeviceStatus deviceStatusNotNull = testRunner.Result.ShouldNotBeNull();
            deviceStatusNotNull.DeviceAddress.Should().Be(deviceAddress);
            deviceStatusNotNull.IsInNetwork.Should().Be(true);
bkoelman
  • 11
  • 2
1

I don't know the specific library you use, but I'd try something like

Assert.IsTrue(someObject != null);

or, for the sake of completeness,

Assert.IsNotNull(someObject, "someObject must not be null");
Assert.IsNotNull(someObject.SomeProperty, "SomeProperty must not be null either");
Assert.SomethingElse(...);
Alex
  • 23,004
  • 4
  • 39
  • 73
  • Thanks for the answer, but the issue will still exist. Even if I assert the object and the property is not null, the warnings don't care and give the warning anyways. The warnings will only go away if I do a `object == null` and return out of the method. – Brandon Mar 23 '12 at 16:22
  • @Brandon Out of curiosity, despite the warnings, do the tests pass and fail as you would expect ? – Alex Mar 23 '12 at 16:30
  • yes. This is more of a nitpicky issue. I just don't like the solution wide inspections being filled with a bunch of warnings that shouldn't actually be warnings. This doesn't affect the actual code or the testing or anything. – Brandon Mar 23 '12 at 16:33
  • @Brandon Oh my, I get it now, they come from ReSharper not from the compiler ... My bad. That dumb thing should provide facilities to instruct it to shut up, but I never used it so I'm afraid I can't provide further advice. They aren't *real* warnings anyway (they don't come from the compiler, am I correct ?), so I'd probably just end up ignoring them in your situation....but I'm very lazy when it comes to best practices... – Alex Mar 23 '12 at 16:50
0

You can use ContractAnnotations to indicate the execution stops if parameter is null. See jetbrains contract annotations. Sample class:

 public static class FluentExtensions
 {
        //see: https://www.jetbrains.com/help/resharper/2017.3/Contract_Annotations.html
        [ContractAnnotation("null => stop")]
        public static void ShouldNotBeNull(this object objToTest)
        {
            objToTest.Should().NotBeNull();
        }   

 }

Usage:

doc.ShouldNotBeNull();
doc.Content.ShouldNotBeNull();
0

If I am not mistaken, your problem is that resharper gives warnings when null is not checked foreach object. You can modify resharper rules not to give null warnings in test classes. Here is a link about changing ReSharper naming style for test methods.

daryal
  • 14,643
  • 4
  • 38
  • 54
  • You know you program too much when you start writing for each as one word. :) Could you provide the steps as to how to do this? How do I tell Resharper what to consider a test class? – Brandon Mar 23 '12 at 15:41
  • @Brandon you made me smile:) please have a look; http://atombrenner.blogspot.com/2010/07/how-to-change-resharper-naming-style.html – daryal Mar 23 '12 at 15:46
  • -1 I think you are mistaken. The appearance of the warning is not specific to test classes. – James World Mar 23 '12 at 15:47
  • @JamesWorld the appearance of the warning is not specific to test classes, you are right, but what Brandon needs is to disable the warnings only in test classes if I am not wrong. – daryal Mar 23 '12 at 15:49
  • Disabling warnings en masse is never a good idea - this would hide warnings of genuine concern. – James World Mar 23 '12 at 15:50
  • @JamesWorld, daryal is correct. I want to have the warnings enabled except for in test classes. – Brandon Mar 23 '12 at 15:51
  • Still not a good idea... much better to solve the issue properly or specifically disable the warnings if you really can't find a way. – James World Mar 23 '12 at 15:53
  • @JamesWorld, I don't quite understand the objection. `Assert.IsNotNull` is solving the issue properly. If it does come up as null the test will fail and the method will stop executing. The only issue is the warning that I haven't checked for nulls, when I have. Also, @daryal, that only applies to naming inspections, not anything else including exceptions. – Brandon Mar 23 '12 at 15:58
  • The objection is that if you subsequently add faulty logic to your tests that would have been caught by a warning, then you won't see it. – James World Mar 23 '12 at 15:59
  • @Brandon you should find the null warning in the list and modify it as the page suggests. (In the resharper options find the rule related to the null and continue with what is suggested in the page). – daryal Mar 23 '12 at 16:02
  • What would be nice is if R# noticed the check for null in Assert.IsNotNull, rather than looking for other types of null checks. – Andy Wiesendanger Jun 11 '15 at 18:22
0

Use NUnit instead of MBUnit. NUnit's implementation of Assert.IsNotNull() is picked up as guaranteeing not null whereas MBUnit's is not.

James World
  • 29,019
  • 9
  • 86
  • 120
0

You can use R# external annotations to suppress the warnings (see http://grahamrhay.wordpress.com/2011/01/09/external-annotations/).

What version of MbUnit/Gallio are you using?

grahamrhay
  • 2,046
  • 4
  • 19
  • 29