daveoftheparty / speedy-moq

Generate boilerplate code for Moq in C#
MIT License
1 stars 0 forks source link

support mocking from dependencies #52

Open daveoftheparty opened 2 years ago

daveoftheparty commented 2 years ago

Original intention of this library was to mock your own interfaces in your own project. I chose not to iterate all the interface definitions from all the dependencies because that could be a huge list/task... storing the definitions for all of System.Collections.Generic, for example.

However I am now having some issues where code I am attempting to write (mock) has interfaces defined in other NuGet repos... where I've written (or a team mate) those interfaces. Need the ability to generate moq setups for our OWN 3rd-party dependencies. Maybe load everything except System. and Microsoft. ?? Will need some solutioning

daveoftheparty commented 1 year ago

EARLY on in this project, I had another repo named boiler-moq (to stand for 'boilerplate') and I went down the road of using reflection to get interfaces from a dependency-- until I realized that I wouldn't be able to get interfaces newly added by a user until a build was executed, and I went the Rosyln route.

Anyway, I may want to bring the reflection back in to solve for this issue, unless modifying the current code in InterfaceStore.cs that uses Rosyln to point to a package will work just as well.

I still have some of the code around in a random place on my hard drive in this class:

D:\Dell_E_Temp\is-it-possible\Generator\Generate.cs

according to git status in the folder, my branch is "up to date" with the remote which is listed as https://github.com/daveoftheparty/boiler-moq.git

I don't remember exactly what I did, whether I renamed that boiler-moq repo to this existing speedy-moq or what, but if I enter in that URL I'm always redirected back to this one.

The last commit is the following, and even though these following URLs generate warnings about the commit not being in the repo (maybe in another fork, they say)-- I'm able to retrieve the tree, etc. in case I lose my crappy temp spot on my hard drive.

https://github.com/daveoftheparty/speedy-moq/commit/b4760e75408243a9257c4fc9c154b461ede93447 https://github.com/daveoftheparty/speedy-moq/tree/b4760e75408243a9257c4fc9c154b461ede93447

daveoftheparty commented 1 year ago

Turns out, this may not be needed due to a workaround:

I surprised myself today working on something that I needed to mock Amazon.SQS.IAmazonSQS and it... generated setups!

I also had setups available for Microsoft.Extensions.Options.IOptions

I think it's because I had loaded the metadata for these (ie, in VSCode, highlighted the interface name and pressed F12 to check the interface arguments)

Verify this works in Visual Studio, too?

Because the log out from InterfaceStore to dump all loaded interfaces contained these definitions: Interface File
Amazon.SQS.IAmazonSQS d:\ISS\upside-activity-ingest-worker\omnisharp-metadata:\%24metadata%24\Project\UpsideActivityIngestWorker\Assembly\AWSSDK\SQS\Symbol\Amazon\SQS\%5Bmetadata%5D%20IAmazonSQS.cs
Microsoft.Extensions.Options.IOptions;1 d:\ISS\upside-activity-ingest-worker\omnisharp-metadata:\%24metadata%24\Project\UpsideActivityIngestWorker\Assembly\Microsoft\Extensions\Options\Symbol\Microsoft\Extensions\Options\%5Bmetadata%5D%20IOptions%601.cs

Note the path to the file, contains my hard drive path plus after metadata it includes Project\UpsideActivityIngestWorker where my actual .csproj file name was UpsideActivityIngestWorker.csproj

Potential workaround for needing to moq any interface:

simply load the metadata using F12

Question: does this also work in Visual Studio or other IDEs, though? Or is this a VSCode C# plugin (by OmniSharp) specific workaround?