Create Method Stubs

Dec 4, 2015 at 11:12 AM
Oh man... was the previous thread for this deleted? Looks like I cannot access it.

Anyways, I did take a look at this link:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/06/creating-unit-test-stubs.aspx

And while it technically does do what I was thinking of, it does it in a very disruptive way. I am basically thinking of an Alt-Enter -> Create Test. Boom. Done. No fancy dialogues and heavy decoration (not sure if you have seen Pex, but the attributes are incredibly outrageous and chatty).

Anyways, thanks for any consideration.
Dec 6, 2015 at 1:31 PM
OK, just to verify here. I finally have had the chance to try your extension and the guidance above instead of eyeballing it from afar. :)

I did try to use the above, but now it is IntelliTest, which is the old Pex. Have you tried to use it? It is extremely heavy on the metadata and adds a lot of weight and feel to the generated files.
http://screencast.com/t/00NYEVXclk

It also appears that method stubs are not generated correctly from a xUnit perspective (possible bug).

Additionally, as an FYI, the settings are not persisted between test generations, which is extremely disappointing (reported to Visual Studio team, but thought I would share here, as well:
http://screencast.com/t/9plvPTXzsbcd
Dec 6, 2015 at 1:36 PM
OOPS... I forgot to mention my experience with your extension. It seems I am having trouble with getting a test class to honor the namespace that it was created in. For instance, I have a DragonSpark.Modularity.ModuleAttribute.cs file:
http://screencast.com/t/yiPsbP2KENU

But when I CTRL-G -> CTRL-T it, it puts the class file in the root:
http://screencast.com/t/sxxnQjKI

I would expect it to create a "Modularity" folder and put it in there. Is this possible? Here are my settings:
http://screencast.com/t/0gvziknl

Thank you for any assistance. :)
Coordinator
Dec 6, 2015 at 2:51 PM
I will take a look. Do you use one unit test project for all your code classes?
Dec 6, 2015 at 3:45 PM
Indeed I do. Please look at the .SLN found here if you are interested in trying it out (xUnit 2.0 and all :) ):
https://github.com/DragonSpark/Framework/tree/Multiversal
Coordinator
Dec 6, 2015 at 7:53 PM
The best choice for the project you shared in GitHub is to use the 'test project per code project linked by namespace' with the regex ^(.*?)\.?Testing?$
Note you'd need to create a project DragonSpark.Client.Testing if you needed to test the client project.

'test project per code project linked by namespace
regex

Otherwise...
a single test project for your solution isn't possible unless you consider changing DragonSpark project namespace to DragonSpark.Core (or similar). The reason is that when the code sees the class DragonSpark.Testing.Client.ClassA and DragonSpark.Testing,Modularity.ClassB it uses a single regex to work out the code project.


Given the namespace of a test such as DragonSpark.Testing.Modularity or DragonSpark.Testing then the following regex will work out that the code project is DragonSpark and the sub folder/namespace is everything after 'Testing'

Test NameSpace: ^(.*)\.Testing(\..*?)?$
Code Assembly Namespace RegEx Replace: $1
Code Assembly SubNamespace RegEx Replace: $2


The next set of regex describe how the namespace of a code file match to the test. The regex below is basically saying everything after the first '.' is namespace to be copied across to the test. e.g DragonSpark.Modularity -> .Modularity

Code Namespace: ^(.*?)(\..*?)$
Code to Test assembly Namespace Regex: S2

DragonSpark TestCop settings
Dec 6, 2015 at 8:44 PM
Thank you for taking the time to look into this and for explaining it. I did intend on having just one testing assembly for the entire solution, but I might have to reconsider that now that I eventually will be supporting different platforms (and obviously that will not work with just one assembly). Let me think about this. Please do not delete this thread until I let you know I have a solution. Maybe in the next day or so. :)

Thanks again... much appreciated.
Dec 8, 2015 at 12:54 PM
OK I finally got a chance to work a little with this. The first suggestion worked like a champ, thank you.

Additionally, some food for thought: I do have a lot of RegEx experience, but by no means an expert. I do appreciate the approach here, however RegEx is a little wonky to work with as I am sure you have already received feedback around. Additionally, it seems as if you can access the project's root namespace from the csproj file somehow? That seems like something that should be baked into R# as that is used to Refactor -> Adjust namespaces (and for incorrect namespaces found in files).

Finally, please consider keeping this discussion in tact instead of deleting it. Or rather, deleting any discussion, for that matter. Other developers might find it/them useful in the future. Just a thought. :)

Thanks again,
Michael
Coordinator
Dec 8, 2015 at 8:56 PM
Edited Dec 8, 2015 at 8:57 PM
Excellent. Good to hear you've got it working.

The RegEx approach is a necessary evil until I (or somebody else) comes up with a better way. The plugin used to be pretty simple until I added support for different ways of setting up test projects. Who knew there were so many !

Even with the simple strategy of a "single test project per code project" it proved to be an area of contention. Some developers have

MyCorp.MyApp.DAL.Testing

others

MyCorp.MyApp.DAL.Tests

or MyCorp.MyApp.DALTests

and even

MyCorp.MyApp.Tests.DAL

or

Tests.MyCorp.MyApp.DAL

to hold unit tests for the code project MyCorp.MyApp.DAL. Using a RegEx means TestCop can support all these.
Dec 8, 2015 at 8:59 PM
Yeah I can see how it can work, and understand how it evolved. It's a very understandable approach. Is it not possible to access the csproj data from R#, however? It is used in doing the Refactor -> Adjust Namespaces. That seems like it might be a place to start. But again, I'm not the one coding it. :)

Anyways, thanks for your help, time, and response!
Dec 12, 2015 at 8:57 PM
FWIW I have a really great setup now with TestCop for the class files, and ZenSharp for the methods:
https://github.com/ulex/ZenSharp/issues/21

Thanks again. :) So much better now!