Replies: 1 comment
-
|
My mentality is always to try and build things in an extensible way that tries to cover 99% of use cases, without tightly coupling to a specific implementation. So absolutely happy to try and make something like this happen if it can be designed in a way that works with extension points or something 😁 This is a good time to think of what is needed though. As it's still in beta I can still "break" the API if needed to support these enhancements |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
TUnit has quickly become my favorite testing framework (awesome work on this).
I am one of the maintainers of Moq.AutoMock. The intent with this library is to be able to decouple tests from a type's constructor by automatically injecting mocks (or other test doubles). Obviously, that library is built on top of Moq, and does leverage reflection to do its work.
I have been keeping an eye on
TUnit.Mocksand wondering if there is any desire to have similar functionality as part of it? I would also be happy to help contributes to such an effort as well if this would be a desirable addition.Beta Was this translation helpful? Give feedback.
All reactions