Disable analysis for test assemblies

Question

Disable analysis for test assemblies

espenalb opened this issue 9 years ago · comments

Espen Halsaa Albrektsen commented 9 years ago

Hi - and thanks for an excellent plugin!

I see that you have a test asserting that the extension ignores test classes, but I did not figure out how it works.

Do your require that test classes start with test? Or is there some other mechanism at play here?

We are using another R# extension – TestCop – which aligns our test code with production code through namespaces and a simple RegEx.

Common.Utils.SomeClass defined in Common.dll has test code defined in Common.Tests.dll, namespace Common.Tests.Utils.SomeClassTests

This pattern is not recognized by your extension, and we therefore get a lot of “noise” in our test code where ConfigureAwait makes less sense…

Any chance you could fix this? Or anything I could do on my side to fix this?

Eli Arbel · Answer 1 · Sun Oct 25 2015 16:01:17 GMT+0800 (China Standard Time)

Sorry for the late response.

There's no feature that ignores tests (I don't know where you saw the assert you spoke of). Filtering by class names is a feature that has been requested (see #4), so I may add it at one point. For now, you can use this attribute on your test classes to suppress the warnings:

[SuppressMessage("ReSharper", "ConsiderUsingConfigureAwait")]

Espen Halsaa Albrektsen · Answer 2 · Tue Oct 27 2015 22:22:36 GMT+0800 (China Standard Time)

OK. Works as expected. I think it would be very useful to implement #4 - there are typically namespaces where ConfigureAwait(false) will crash the application...

Blake Niemyjski · Answer 3 · Wed Nov 25 2015 21:36:28 GMT+0800 (China Standard Time)

It should only ask to configure await in class libraries. Also, I have an extension method called AnyContext() which sets ConfigureAwait(false), would this plugin be smart enough to detect this?

Eli Arbel · Answer 4 · Thu Nov 26 2015 00:16:14 GMT+0800 (China Standard Time)

Yes. The extension checks whether the awaited expression's type is a Task,
and if so, issues the warning. I'm assuming AnyContext() returns an
awaitable, which should be fine.

Joseph Musser · Answer 5 · Sat Nov 12 2016 05:04:15 GMT+0800 (China Standard Time)

I'm willing to work on this.
Ideally it should entirely skip test projects, right? Looking for <OutputType>Library</OutputType> and <ProjectTypeGuids> not containing {3AC096D0-A1C2-E12C-1390-A8335801FDAB} (test) or any of the MVC project type guids?

Blake Niemyjski · Answer 6 · Sat Nov 12 2016 05:38:51 GMT+0800 (China Standard Time)

It should skip entry points (gui projects, web projects and test projects)

Thanks
-Blake Niemyjski

On Fri, Nov 11, 2016 at 3:04 PM, Joseph Musser notifications@github.com
wrote:

I'm willing to work on this.
Ideally it should entirely skip test projects, right?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-SoxHySGMgqfNQhDJHjQndtPy0wzvWks5q9NhQgaJpZM4GN2-M
.

Joseph Musser · Answer 7 · Sat Nov 12 2016 08:29:32 GMT+0800 (China Standard Time)

Technically web and test projects don't have entry points represented in the .csproj or any other file, right? The tooling just works around the .csproj guids I'm pretty sure. The build output in both cases is a DLL with no entry point and then vstest or IIS Express is invoked on it?

Eli Arbel · Answer 8 · Sun Nov 13 2016 00:09:10 GMT+0800 (China Standard Time)

I wouldn't attempt to apply this automatically to predetermined project types.

Instead I suggest an assembly-level attribute:

[assembly: SuppressMessage("ReSharper", "ConsiderUsingConfigureAwait")]

Joseph Musser · Answer 9 · Sun Nov 13 2016 03:32:28 GMT+0800 (China Standard Time)

@aelij no one I can think of will ever want ConfigureAwait(false) enforcement in a WPF or Windows Forms or ASP.NET app, and it's unlikely for a console app too. Wouldn't it be better to ignore them by default and, if anything, allow opt-in using an assembly attribute?

Eli Arbel · Answer 10 · Thu Nov 17 2016 15:10:20 GMT+0800 (China Standard Time)

@jnm2 I would rather it be opt-in and not automatic. Even in WPF programs, there are a lot of places where not going back to the dispatcher thread makes sense.

Joseph Musser · Answer 11 · Tue Nov 22 2016 06:36:36 GMT+0800 (China Standard Time)

@aelij I think we just used 'opt-in' to mean opposite things, but I'm good with whatever you think makes sense. Just so I'm not confused, you think it's best to get warnings by default in test projects until you opt out of warnings, rather than not getting warnings by default in test projects unless you opt in to warnings?

Eli Arbel · Answer 12 · Tue Nov 22 2016 16:31:09 GMT+0800 (China Standard Time)

@jnm2 Yes. As with all ReSharper suppression attributes, it would disable the warnings.

Joseph Musser · Answer 13 · Tue Nov 22 2016 22:09:43 GMT+0800 (China Standard Time)

@aelij I wish there could be a way to use a new attribute that ConfigureAwaitChecker would recognize that would allow opting in (for test assemblies) as well opting out (for class libraries). Without that, this extension will be less useful to me. I work on so many projects where I can't just put warning suppression for my extensions in other people's code. I'll just have to get used to ignoring the underline.