2

I have just recently started using ReSharper and am looking for a way of resolving a particular issue I have with the "Type argument specification is redundant" tooltip/quickfix. When writing unit tests I have been using Assert.AreEqual<string>(x, y) and ReSharper flags the usage of <string> as redundant. I would like to not have that flagged as redundant for that or any similar usages in my unit tests. Is there any way to disable this particular usage case (which would be extensible to the other assertions)? Please note, I would like to avoid the suppress with comment because of the large amount of noise that would create in the source file. I also don't want to disable the feature entirely.

For clarification, the reason this particular case is incorrectly flagged in my opinion is because the usage of the generic causes the error of mismatched types in the assert to be flagged at compile time and not at test runtime. I would like to keep this fail early behavior but get rid of all the extra noise this causes in basically every test I write.

Thanks

Edit: There has been a question about what the test contents would look like so I'm providing an example of one such assertion that is causing ReSharper to flag the redundancy.

[TestMethod]
public void ViewModelConstructor_NullProgram_SetsVisibilityToCollapsed()
{
    _currentProgram = null; //Set condition under test
    var Target = TargetMaker(); //Use shared constructor code in all tests
    Assert.AreEqual<System.Windows.Visibility>(System.Windows.Visibility.Collapsed, Target.SectionVisibility);
}

Edit 2: Here's an example of the before and after ReSharper's suggested change. These two pieces of code show very different results. I've noted the different behaviors in the test function names. 

class ClassUnderTest
{
    public string fieldUnderTest { get; set; }
    public ClassUnderTest()
    {
        fieldUnderTest = "New Value";
    }
}


[TestClass()]
public class ClassUnderTestTest
{

    [TestMethod()]
    public void ClassUnderTestConstructorTest_FailsTest()
    {
        ClassUnderTest target = new ClassUnderTest();
        Assert.AreEqual(true, target.fieldUnderTest);
    }

    [TestMethod()]
    public void ClassUnderTestConstructorTest_WontCompile()
    {
        ClassUnderTest target = new ClassUnderTest();
        Assert.AreEqual<string>(true, target.fieldUnderTest);
    }
}
Mark Smith
  • 1,085
  • 8
  • 19
  • why don't you just disable it for your unit test project? – Daniel A. White Feb 27 '12 at 14:10
  • The major reason would be I couldn't find anywhere to set that on a per project basis. I can only find the general severity setting for that feature. Where is the per project setting? – Mark Smith Feb 27 '12 at 14:20
  • 1
    If you're saying that R# is suggesting removing an explicit type argument, and doing so causes the behaviour to change, then that's a bug in R# and should be raised as such. It's not 'redundant' if its presence causes something different to happen, after all. However, I'm not entirely sure I can visualize your code... – AakashM Feb 27 '12 at 16:53
  • @AakashM I raised this issue about a week ago on the ReSharper forums and didn't get a single response from anyone in that community, so while I would love to see this fixed, I don't exactly see them chomping at the bit to do so. And Yes it does cause different behaviors. Without the generic, it treats both sides as objects and compares. Where as the strongly typed version fails at compile time. – Mark Smith Feb 27 '12 at 18:19
  • Rather than the forums (which I should say I've never used), if you have a simple repro I would go straight for the bug tracker - I've [reported a number of issues](http://youtrack.jetbrains.com/issues/RSRP?q=by%3A+aakashm+) there myself, and more than none have so far been fixed :) You can vote on issues there too, although I don't have any*direct* evidence that votes influence the order in which things are looked at... – AakashM Feb 27 '12 at 22:18
  • @Mark Dickinson Any refactor operation should not alter the fundamental operation of the code. If ReSharper is suggesting this as a refactor and the result does not compile, it isn't a very effective refactor. That's the equivalent of refactoring `asdf x = x+5;` to 'x+=5;` Fundamentally I haven't changed what happens to x if you can get past the point that the refactored code no longer compiles. But I digress, in no way is this question about the accuracy of the operation. The question is about how to suppress the warnings. Of which so far Ani is the closest, and AakashM has made valid points. – Mark Smith Feb 28 '12 at 00:57
  • Would it be fair to say that you've simplified the code you are showing. Have you got a prototype or some other creational pattern that gives you different classes that could be the subject of the test. Your example tests a boolean against fieldUnderTest (string?). I know I haven't helped in the slightest so I'll clear off my noise. Good luck sorting it out :) – Mark Dickinson Feb 28 '12 at 09:36
  • For me Edit 2 doesn't really clear things up. With that non-compiling code present, R# *doesn't* suggest removing the type argument. If `true` is changed to `"true"`, so it compiles, R# *does* suggest removing it, but the behaviour is not altered by doing so. – AakashM Feb 28 '12 at 11:33
  • @AakashM - From the standpoint of the compiler output you are 100% correct. I decompiled all the different variants of that assertion and they all restrict it to the most efficient implementation. I was even surprised the `Assert.AreEqual(null, target.fieldUnderTest);` still called the string comparison method and not object method. So while the output is in no shape altered, I guess what I don't agree with is removing the constraint from the compiler. Removing the constraint allows the compiler to loosen the method call to `(object, object)` if the test code were to change. – Mark Smith Feb 28 '12 at 13:40

3 Answers3

2

Resharper 6.1 introduces the concept of settings-"layers". Here's a blog-post that teaches you how to setup per-project settings, which is what you appear to want.

Ani
  • 111,048
  • 26
  • 262
  • 307
  • This looks like Daniel was getting at and it would be great but I can't seem to get it to work. I created a layer like your link stated. I disabled the option that's bothering me for my test project in that layer. I saved it and unchecked the file like mentioned in the Blog. The error is still being flagged though. I reloaded Visual Studio and the error is still flagged. I disabled the option through the tooltip and saved it to my new layer through the save to dialogue and it is still flagging it. The DotSettings file is named after the project as well. Any idea where I went wrong? – Mark Smith Feb 27 '12 at 14:37
  • The GUI is in fact updating the setting for the value in the DotSettings file created but the setting is not being applied to the current source file. – Mark Smith Feb 27 '12 at 15:57
  • Marking as accepted since this is a viable solution for what I want and hopefully when R# does the GUI support for the layers this will work and resolve my issue. – Mark Smith Feb 29 '12 at 14:52
0

Click the redundent part and then click to the left of the line and choose Inspection option for Redundent.... There you can choose a lower restriction level until your like it.

radbyx
  • 9,352
  • 21
  • 84
  • 127
0

You don't have to surround with comments each instance of Assert.AreEqual. Instead, you can use comments to this highlighting in the entire source file. Just add one disabling comment at the start of the file and one enabling - at the end. Minimum noise.

Dmitry Osinovskiy
  • 9,999
  • 1
  • 47
  • 38