Restrict scope to within Namespace usage.

[AdamSpeight2008]

Restrict a scope to be only accessible to within a namespace, would be used for sharing methods across different assemblies. Without resorting using public methods. Especially useful for unit test assemblies.

[YairHalberstadt]

Sharing a method with unit test assemblies is usually done using the InternalsVisibleToAttribute.

This has 2 advantages:

1. It doesn't require the unit tests to be in the same namespace as the type they're testing.

2. It prevents anyone other than those assemblies given access to the type from using it, whereas anyone can declare that a type is in whatever namespace they want.

[DavidArno]

I would argue that sharing a method with unit test assemblies should always be achieved through it being public. In other words, unless a method is public, then it's an implementation detail and should never be directly tested.

If code can't be indirectly accessed through a public API, then get rid of it as it serves no purpose. What's left is then fully testable through tests that simply use those public APIs.

The idea that because I declare a type in namespace Foo.Bar, I can suddenly access all internals in any other assembly that also reside in Foo.Bar would render internal meaningless. I can then easily work around that internal by replicating a namespace to effectively make it public. It then becomes a public API and can no longer be treated as an implementation detail as other code - outside the assembly - may be dependent upon it.

[CyrusNajmabadi]

I would argue that sharing a method with unit test assemblies should always be achieved through it being public.

'public' is a mtter of perspective. If i build and deliver an API, i can choose to make it "public" only to a limited set of consumers (using internal) or i can make it "broadly public" using public. THe former is just as valid as use case, and still benefits from the same sort of testing as the latter.