search

machine / machine.specifications

Machine.Specifications is a Context/Specification framework for .NET that removes language noise and simplifies tests.
MIT License
886 stars 178 forks source link

Future of Machine.Fakes #390

Open robertcoltheart opened 5 years ago

robertcoltheart commented 5 years ago

In projects I've worked with we've noticed that we don't deviate from one flavor of Machine.Fakes (in our case Moq). For the rare cases where we've needed additional control over the mocking, we just reference Moq directly and use it as normal.

In addition to the above, the overhead in supporting multiple frameworks is a bit overbearing, and also prevents, to varying degrees, those frameworks from progressing. Also RhinoMocks is basically abandoned, and will never support netstandard.

On a picky note, it's always irked me that the package and namespace does not line up with Machine.Specifications. One benefit of aligning Fakes to Mspec would be that we have verified packages on Nuget for Machine.Specifications.*.

To solve the above, I propose a new package, Machine.Specifications.Fakes. This would be a single package that depends on Castle.Core and would be a home-grown fake library. We would still allow extensions points like IFakeEngine so that consumers could implement their own flavor of Fakes for Moq or FakeItEasy etc. I'm happy to archive the code we have for these implementations or move them to an 'example' project or something, but to cease maintaining them.

Users that, for whatever reason, insist on using the current Machine.Fakes can continue to do so under version 1.0 of MSpec.

IndikaUdagedara commented 4 years ago

On the flip-side, I was wondering why MSpec has it's own fake library - especially given the smaller community (IMO) contributing to the project, do you think there will be enough support to maintain both MSpec and MFakes? Wouldn't it be better to leave the fakes out of MSpec altogether and let the users pick their favorite (same way XUnit does for example)? The main reason I turned to MSpec is due to its elegant specification grammar and I believe most other users would have a similar reason. For mocks/fakes, there are already number of very mature frameworks so why take on the extra challenge instead of improving MSpec?

robertcoltheart commented 4 years ago

The fakes library removes a lot of boilerplate code, it's worth keeping if only to not break a lot of code out there that is using it. See https://github.com/machine/machine.specifications/wiki/Fakes