Add proposal for out of the box fuzzing

[samueleresca]

Adding a proposal for including fuzz testing as part of the .NET toolchain.

[rstm-sf]

It seems to me that the property base tests should also be covered. FsCheck is an example of a .NET library which is a port of QuickCheck

[danmoseley]

Cc @jeffhandley

[svick]

This sounds useful to me, but I'm not clear on why it should be part of the .Net SDK, instead of a tool that can be installed using dotnet tool install.

[samueleresca]

This sounds useful to me, but I'm not clear why it should be part of the .Net SDK, instead of a tool that can be installed using dotnet tool install.

Instrumenting the target and running the fuzzing usually require some overhead.
having this process supported as part of the SDK would provide a unified experience. Using an external tool might mean that you need to tweak it depending on which platform you are on (for example, I think sharp fuzz runs only on Linux and macOS).

[danmoseley]

Cc @krwq @GrabYourPitchforks

[jkotas]

having this process supported as part of the SDK would provide a unified experience. Using an external tool might mean that you need to tweak it depending on which platform you are on

You can bundle the external dependencies into the tool package to provide unified experience, just like you would bundle them into the SDK to provide uniform experience.

It is better to start by independent package for features like this. You can react to feedback and iterate quicky, and you have a lot of freedom for making breaking changes.

And then consider integrating with the SDK only once you have validated on real world use cases that the experience is right and stable. Once you integrate with SDK, the bar rises a lot: You need to worry about backward compatibility, aligning with SDK ship schedule, etc.

[jeffhandley]

We have had some recent prototype efforts internally in this space. We are exploring some possible paths forward while we conduct our .NET 8 planning.

[GrabYourPitchforks]

Took the conversation offline. Like Jeff said, we've done some internal prototyping, but nothing that's really in a position to show at the moment.

I propose we close this issue since it's not immediately actionable and it's already being tracked in a separate database.

[samueleresca]

Closing. See the reasons mentioned above