matkoch / resharper-testlinker

Easy navigation between test and production code.
MIT License
28 stars 11 forks source link

Support for Multiple Projects #10

Open Mike-E-angelo opened 6 years ago

Mike-E-angelo commented 6 years ago

To start with, great project here. I have been using it alongside with ReSharperHelpers and have a really solid testing experience now in R# and Visual Studio.

Of course, having two testing extensions means that one can lose context of exactly which extension is performing which feature. And that one is ME as I have already posted this request in ReSharperHelpers' repo thinking that the behavior I was seeing was from over there, DOH!

It turns out that it could also benefit from this, as well, so maybe not all is lost. 😆 Here is the post from there pasted here for your reference/convenience.


Consider the following assemblies:

Namespace
Namespace.Other
Namespace.Testing

I would like to have Namespace.Testing handle the tests for both assemblies. When a test from Namespace.Other is generated, ideally it would go into Namespace.Testing.Other. I tried playing around with this and didn't have much luck, Nothing obvious was found in the settings.

So to clarify, everything everything does work really well without any setup. The only issue that I have experienced is the initial location of the created file in this case.

Thank you for any consideration towards this!

matkoch commented 6 years ago

Hi Mike,

I guess this requires some changes here: https://github.com/matkoch/TestLinker/blob/master/src/TestLinker/Utils/ModificationUtility.cs

TestLinker tries to find another candidate where it can derive information from. I will try to look into this a little later this month.

Mike-E-angelo commented 6 years ago

Cool thank you for the reply @matkoch ... also, is that your way of asking for a PR? 😆

matkoch commented 6 years ago

In some sense :) It isn't really top priority, as you probably can guess. But be assured that I'll look into this eventually.

Mike-E-angelo commented 4 years ago

I think I just got bit by this again, but it's a little more extreme.

Consider the following class libraries:

Framework
Application

And subsequent testing assemblies:

Framework.Testing
Application.Testing

I have created tests in both of these assemblies and am targeting Application.Testing.Security.Profile namespace. I have ensured there's a test in this folder.

However, when invoking Resharper_GoToLinkedTypesAction on Application.Security.Profile.Class, it attempts to put it into Framework.Testing.Security.Profile.Class.

Is there a setting somewhere I am overlooking, perhaps?

Mike-E-angelo commented 4 years ago

So putting more thought into this. 😁

Currently there are SubjectAttribute searches done from Test -> Subject. However, what appears to be missing is the inverse: Subject -> Test.

Might it be possible to introduce an assembly-level hint attribute that assists in determining the appropriate assembly to search? Something like:

[assembly: ExternalAssemblyHint("Framework.Testing")]

For subject assemblies being hosted in a provided folder within a test project:

[assembly: ExternalAssemblyHint("Framework.Testing", "FolderName")]

Ideally, this attribute would work like JetBrains.Annotations and not make it into Release builds.

matkoch commented 4 years ago

@Mike-E-wins I think I've overpromised early in this thread, saying I will look into this eventually :) I'm still hoping for ReSharper to merge this feature into the product at some point. Until then, I guess it's best to keep at the current feature level, to not overcomplicate things. But of course, the issue can remain open here.

Mike-E-angelo commented 4 years ago

Hehe no worries @matkoch that works for me. Maybe someone can look at this for reference when it is integrated to hopefully improve upon it.

It still amazes me we are in 2020 and there doesn't seem to be any good quality/consistent way to get tests generated for classes in a .NET solution. Well, outside of the basic scenarios, that is, as this plugin does that really well. 😁

Outside of that, however, maybe this is why TDD faces such friction in adoption. Certainly friction in general. :P