ReSharper Suggestions for Expected vs. Actual

Topics: ReSharper test runner
Jul 13, 2010 at 7:34 PM
This has sort of bugged me for a long time now. Why does ReSharper suggest variables/values for Assert.Equal's "expected" argument that feel like they should be suggestions for the "actual" argument, and vice versa? When I type "Assert.Equal(", ReSharper shows me a list of variables, defaulting to the most recent one constructed in my test method. However, that's what I want it to suggest for the 2nd argument; the one for the actual value. Likewise, after I force my constant value or otherwise expected value in for the first argument, ReSharper suggests things like int.MaxValue that I would expect to see for the "expected" argument. Is there a way to inform ReSharper that the order of these assertion parameters are different than what it thinks they are? Thanks!
Coordinator
Jul 13, 2010 at 9:13 PM

Assuming this is from the live template, it's actually doing the right thing.

Both parameters are using the same SmartType macro, but they are showing different lists, which seems a bit odd, but it does make sense.

Assert.Equal is a generic method, Assert.Equal<T>(T, T). When you type "Assert.Equal(" ReSharper doesn't know what type T is, so offers the appropriate list (which in a quick test included all local methods, GetType, GetHashCode, MemberwiseClone, etc and all local variables, i, j, etc). Once you choose the "expected" value, ReSharper knows the type of the "actual" value, and can display a more appropriate list.

There's not too much can be done here. If you swap the order of the macro evaluations so that "actual" is handled first, you get the intellisense drop down for "actual", but choosing a value doesn't give enough type information for the "expected" value.

Or you could change the template to include the <T> in Assert.Equal<T>(... Then when using the template, enter "int" as the type T, and both "expected" and "actual" will provide a shorter list of candidates. But then ReSharper complains that the <int> is not required...