-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove necessity of Moq on external methods #110
Comments
The idea of replacing Moq with a pluggable factory had come up before... I can't find the GitHub issue, though. Maybe it was a discussion on Gitter? 🤔 Regardless... I'd be happy to review an API proposal that refactors the mocking framework into a separate dependency. It might make sense to start by listing the public APIs that introduce the Moq dependency. Then for each, we should review alternatives. Should we use a mock factory? Should we switch to a fake implementation? I think the ideal solution will introduce minimal/no breaking changes for existing consumers. Maybe we refactor the TestKit to have a core library that exposes generic/factory methods and the fake implementations. Then we can introduce separate mocking framework-specific libraries that build on top of the core that expose helper/strongly typed methods. If the signatures in a Moq-specific library didn't change, it could be a really easy transition for existing users. For context: When we created the TestKit, it was our answer to unit testing using Moq to handle the complexity of introducing test doubles for framework components. Moq was a hard requirement and exposing it through the public API intentional. However, over time several mocks have been replaced with fake implementations. As you point out, there are some parts of the library that don't really depend on Moq anymore. It sounds reasonable to think this trend can continue and the TestKit could become more general purpose. |
Yep completely agree on no breaking changes for existing users. And like this idea of having different adapters for different testing frameworks. I'm keen on a fake implementation being passed in via an interface input, but will read through the code to see if this is applicable in all the scenarios where Moq is introduced. I will start going through all externally exposed APIs, but will probably only change a couple of the main ones as I feel most of the value can be achieved with a handful of the signatures. This can then be expanded upon further in future. Thanks, Huw |
Hi guys,
I really like the idea of this package, but having a hard dependency on Moq is not something that's palatable for my team.
I'm happy with the internal workings of this package using Moq, but would like this package to enable the end-user to use whatever mocking framework they want when using this package.
It seems like this is partially supported already with the Silo ServiceProvider (allowing an instance or a Mock -
OrleansTestKit/src/OrleansTestKit/Services/TestServiceProvider.cs
Lines 61 to 72 in f279cfc
But for grain probes, it seems like I can't register an instance of the grain via the AddProbe method on the Silo without using Moq in some way -
OrleansTestKit/src/OrleansTestKit/GrainProbeExtensions.cs
Lines 64 to 73 in f279cfc
I'm thinking of overloading the GrainProbeExtensions' AddProbe method to allow the user to pass in simply a factory method that returns the interface of the grain rather than a IMock, as it seems like we're only using the instance in the GrainFactory regardless.
OrleansTestKit/src/OrleansTestKit/TestGrainFactory.cs
Lines 111 to 144 in f279cfc
Please let me know what you think and if I'm missing something that would make this undoable.
Thanks,
Huw
The text was updated successfully, but these errors were encountered: