Consider an `InternalsVisibleTo`-type Attribute for Locating Testing Projects

[Mike-E-angelo]

I am running into a scenario in a solution with many projects (about 40 of them) where the regex location seems to fail me.

That is, in this scheme, there seems to be overlap with two of the scenarios described in the wiki. To start, there are many projects that do not have a dedicated test project based on namespace/project, but they all share one central one (usage #3). Yet, there are still others that do have their own dedicated projects based on a namespace (usage #1).

So, a combination of scenarios one and three as described in the Wiki if I understand correctly, and a result TestCop never seems to know which one to use when I try to create a test in an assembly that doesn't conform to the configuration applied in settings.

It got me thinking: what if there was a way to somehow "hint" to TestCop to look in a particular project per-project, much like how the InternalsVisibleTo attribute works.

It could work by pointing TestCop to the project and an optional folder, if supplied.

So, in the case of the project Application.Composition as an example, it could look in an Application.Testing project, in the Composition folder with the following "hint" attribute applied to its assembly:

[assembly: TestingAssemblyHint("Application.Testing", "Composition")]

Pressing CTRL-G, CTRL-T on Application.Composition.NewComponent, Application.Composition with the above attribute applied to its assembly/project would point it to create the test file located at Application.Testing.Composition.NewComponentTests, Application.Testing.

This could also be an MSBuild project property as well. This might actually be a better solution to do so as it won't compile into the assembly (but that is not a big price to pay if it means deterministically getting tests made!).

Anyways, I wanted to suggest it to see how difficult it would be, and/or if there is something else that I am not considering here. Thank you for any assistance/consideration!

[testcop]

Testcop can store the config per solution but that doesn't help if you have different patterns within the same solution.

I can envisage using TestingAssemblyHint to drive the methods GetAssociatedProjectFor() and IsTestProject() but the complexity I always found was deriving the folder the testclass should be under...only possible if I know how to transform the full namespace of the class under test to that of the full namespace of the test class (taking into account the namespace of the project itself). How consistent are your folder structures for class and test class?

[Mike-E-angelo]

How consistent are your folder structures for class and test class?

Generally (if not always) I would like to follow the first usage you have described in the wiki. So, mirrored namespaces separated by the Testing token in the testing project. However that doesn't always pan out, as you can see.

For a good example of what I am going through, consider my framework (most recent branch):

https://github.com/DragonSpark/Framework/tree/projects/Starbeam/

Here you can see there's a Composition project (link) but there is no testing project for it. I am putting it in a Composition folder in the root testing folder (link).

Poor discipline on my part, perhaps. But I already have dozens of projects in my folder and the thought of doing one-test-project-per-project terrifies me. 😆 So I have testing projects aligned by tier: Core, Application (Server, Services, etc). There's also more, but that's the gist of my approach. Adding a test-project for each project would crowd an already-crowded structure IMO.

In any case, thank you for entertaining the idea!

[testcop]

I'll take a look at your repo and see what is possible over the next few evenings..

[Mike-E-angelo]

FWIW I bit the bullet and made separate testing projects for my different assemblies and it works well. I hate polluting my solution with so many projects, but alas that appears to be the state of the matter. That stated, I am OK with closing this issue unless you've already put time into it (or someone else would like to see it).