Remove or replace articles (or sections) pertaining to Moq as a recommended testing framework

[IEvangelist]

Any and all places where Moq is recommended, or used will need to be updated. We should take the following action:

• Replace articles (or sections) pertaining to Moq as a recommended testing framework with NSubstitute.
• Remove articles (or sections) that cannot otherwise be replaced.

See: https://github.com/moq/moq/issues/1372

There's a serious privacy concern, as a result this package no longer instills trust. We'll explore replacing it with NSubstitute where applicable.

---

Associated WorkItem - 145863

[webprofusion-chrisc]

This issue is no longer valid. The related change to Moq has been reverted and nothing in the docs refers to a specifically affected version of Moq.

On the idealogical concerns, Microsoft has a moral responsibility to encourage sustainable development models and the bug is actually in NuGet lacking proper support for paid packages.

[jaredthirsk]

This issue is no longer valid. The related change to Moq has been reverted ...

Part of the issue is "this package no longer instills trust". Has trust also been reverted?

On the idealogical concerns, Microsoft has a moral responsibility to encourage sustainable development models and the bug is actually in NuGet lacking proper support for paid packages.

While that may be true, a more urgent reality is that FOSS library maintainers have a practical responsibility to avoid breaking trust, and if it has been broken, to seek to restore it and good will. Have trust and good will been restored?

[GerardSmit]

The related change to Moq has been reverted and nothing in the docs refers to a specifically affected version of Moq.

From what we've seen SponsorLink will be re-added in Moq (see dotnet/runtime#90222 (comment) and https://github.com/moq/moq/pull/1375) when:

1. The build doesn't fail in Mac/Linux
2. A GUID will be used instead of an hashed mail

Note that the build delay isn't mentioned, HTTP-request (that'll leak your IP) and the analyzer still has to read/write files from your appdata folder.

... NuGet lacking proper support for paid packages.

Is there an active feature request in https://github.com/NuGet/Home/issues for this? This way people can vote for this feature.

[ColinM9991]

There does already seem to be several recommended mocking frameworks, including NSubstitute, in the docs.

I'm happy to help with this change but would need to understand first what the desired state is.

Do you want to scrub all references to Moq? This I wouldn't recommend of course as it's a bit drastic.

Alternatively, do you want to update documents that exclusively reference Moq as a recommended testing framework to add some more variety in those documents?

[BenjaminAbt]

This issue is no longer valid. The related change to Moq has been reverted and nothing in the docs refers to a specifically affected version of Moq.

The issue is still there, especially because the developer has already announced SponsorLink will come back into Moq.

Furthermore, Microsoft has a responsibility to provide documentation that expresses a certain level of trust.
Moq has proven that this cannot be fulfilled.

[cmjdiff]

I'm happy to help with this change but would need to understand first what the desired state is.

The desired state is that Microsoft-endorsed documents do not endorse products containing malware where the maintainer has expressed a clear intent to continue shipping said malware (devlooped/SponsorLink#18 (comment)).

Do you want to scrub all references to Moq? This I wouldn't recommend of course as it's a bit drastic.

Alternatively, do you want to update documents that exclusively reference Moq as a recommended testing framework to add some more variety in those documents?

Maybe you had some difficulty in comprehending the original issue? Microsoft should neither ship nor endorse documents that encourage or suggest the use of libraries tainted by knowing and deliberate inclusion of malware by an author who refuses to kill said malware.

[ColinM9991]

I'm happy to help with this change but would need to understand first what the desired state is.

The desired state is that Microsoft-endorsed documents do not endorse products containing malware where the maintainer has expressed a clear intent to continue shipping said malware (devlooped/SponsorLink#18 (comment)).

Do you want to scrub all references to Moq? This I wouldn't recommend of course as it's a bit drastic.
Alternatively, do you want to update documents that exclusively reference Moq as a recommended testing framework to add some more variety in those documents?

Maybe you had some difficulty in comprehending the original issue? Microsoft should neither ship nor endorse documents that encourage or suggest the use of libraries tainted by knowing and deliberate inclusion of malware by an author who refuses to kill said malware.

@cmjdiff I had no difficulty in comprehending the original issue, thank you. Do you work for Microsoft and are you answering those questions in an official capacity in related to this change?

The situation with Moq and Kzu's future on Moq continue to unfold. There is still a maintainer, stakx, who has strongly opposed Kzu's efforts in embedding SponsorLink. Since this isn't a drama club (aside from the SponsorLink nonsense yesterday) a level of clarification is certainly a pragmatic approach prior to entire teams committing to a scorched earth approach.

[IEvangelist]

Hi everyone, the reality is that the .NET docs only have a few places where Moq is mentioned—we're not talking about thousands, or even hunderds, we're talking about seven places.

We're going to wait, like advised from Rich here.

[wimme]

I'm a bit surprised here, just handling these seven places and it's a closed deal for Microsoft?
In our company alone, we have thousands of tests using Moq, we can't replace it all this easily. We used Moq because Microsoft has it in their docs and uses it also throughout, so we thought we're also safe to use it.
Microsoft plays a crucial role in the .NET ecosystem and for developers to trust this ecosystem. Just replacing it with something else from one day to another doesn't give much trust. Instead, I'd rather see Microsoft forking it or coming up with a solution for existing Moq tests.

[ColinM9991]

I'm a bit surprised here, just handling these seven places and it's a closed deal for Microsoft? In our company alone, we have thousands of tests using Moq, we can't replace it all this easily. We used Moq because Microsoft has it in their docs and uses it also throughout, so we thought we're also safe to use it. Microsoft plays a crucial role in the .NET ecosystem and for developers to trust this ecosystem. Just replacing it with something else from one day to another doesn't give much trust. Instead, I'd rather see Microsoft forking it or coming up with a solution for existing Moq tests.

@wimme have you read the latest reply just above yours? This issue is a reminder to keep an eye on the situation. Microsoft's stance appears to be on the side of pragmatism by waiting to see how events unfold.

In work, I am in the same situation as you - 6,500 unit tests. Around 75% of those use Moq with AutoFixture.AutoMoq.

Also, just my 2 cents, you shouldn't use a testing framework just because Microsoft reference it. Arguably, Microsoft shouldn't even be endorsing single Frameworks for exactly this reason - it creates a monopoly.

[aL3891]

I believe @IEvangelist was referencing the docs specifically when mentioning "seven places" not the actual code, just to clarify.
adding a warning for now projects for now seems like a great compromise, thank you for looking at this issue.

[IEvangelist]

I believe @IEvangelist was referencing the docs specifically when mentioning "seven places" not the actual code, just to clarify. adding a warning for now projects for now seems like a great compromise, thank you for looking at this issue.

Yes, this only applies to the .NET docs, not anything else at this point.

[IEvangelist]

The corresponding PR was closed, this issue can close now too, see #36638 (comment)