MockFileSystem naming

[fgreinacher]

MockFileSystem actually is no mock l as it doesn’t have any assertions in it. I see it more as an in-memory file system. The same applies to MockFileData and MockDirectoryData.

What do you think of replacing the Mock prefix with InMemory? We could keep the old names for compatibility.

[jpreese]

I do agree that the naming is a little misleading. A lot of people tend to use Mock in place of Stub or simply Fake, but they do have very different meanings. I wrote about it a little while back (https://github.com/jpreese/CSharpUnitTestingBestPractices#lets-speak-the-same-language)

From a verbiage perspective, I prefer Fake as it could be a Mock or a Stub.

We could keep the old names for compatibility.

As in, change the .cs file, but keep the actual class naming the same? While again, I agree the name is a bit off, I don't know if I'm a fan of mismatched naming. I also wonder at this point if while Mock isn't technically correct, the community is comfortable with it.

Irrelevant didn't use to be a word, but people used it so much the dictionary decided to just toss it in one day. Maybe we just roll with Mock?

[rkoeninger]

Yeah, it's the interfaces and abstract base classes that get mocked, not what we call the Mock classes.

Expanding your proposal:

• interfaces and abstract classes keep their current names and live in System.IO.Abstractions.
• pass-through implementations are prefixed with Real and live in System.IO.Abstractions.Real.
• in-memory implementation are prefixed with Fake and live in System.IO.Abstractions.Fake.
• all 3 namespaces are in System.IO.Abstractions.dll so long as the Fake implementations don't introduce unwanted transitive dependencies to production code.

This way, most production code stays abstract by only needing to refer to System.IO.Abstractions to get ahold of the interfaces. .Real and .Fake would only be used in places where dependency injection is set up, or tests.

And there'd only be 2 projects/assemblies: System.IO.Abstractions and System.IO.Abstractions.Tests. (see #271)

Real and Fake could be replaced with PassThrough and InMemory. Real/Fake are short and sweet, but PassThrough/InMemory are more self-descriptive.

More synonyms for Real: Live, Actual

More synonyms for Fake: Simulated, Test, Artificial

There's plenty of bike-shedding opportunity here!

This would definitely be a major release change (3.0) as it would introduce breaking changes.

[fgreinacher]

This needs some deeper thoughts, but as you said let's move the bigger/breaking changes to "v3" (which I just created a milestone for)

[ericnewton76]

Eh, what's the value of doing this? How does it make things better?

I would hesitate with the Fakes being in the core System.IO.Abstractions dll though, due to the potential dependencies issues that might arise. And its just wasted bytes deployed to memory/disk constrained devices.

@rkoeninger problem is production code using the abstractions is absolutely dependent on the Reals, whatever they are called. Moving them around only causes test managers' heads to explode because now there's so much changing from their perspective, even though I agree, (I quote myself:) "its the exact same freakin' code man!!!"

[rkoeninger]

@ericnewton76 I think this is just about making things simple and understandable. Giving something a misleading name just makes it take longer for people to understand how to use the library. But I also understand the desire to avoid making changes for the sake of OCD-gratification - like, I just noticed it's TestingHelpers and TestHelpers.Tests. Where's the ing?! Is it a deal breaker? No. Does it cause me to type the wrong thing occasionally and annoy me? Yes.

File sizes when targeting .NET Framework 4.0: System.IO.Abstractions.dll = 37KB, TestingHelpers.dll = 56KB. There's some overhead between the two that could be shared if compiled together, but I'll let you guys decide if file size is an issue. TestingHelpers has no dependencies outside the BCL. It's just string operations and a dictionary.

[fgreinacher]

I'll close this - assembly/project/NuGet names are now in sync and I think we'd make a lot of people angry if we start renaming classes, namespaces, ...