Internalize types and members that don't need to be exposed

[blairconrad]

Scope to be determined from #374.

[blairconrad]

I'd like to make TypeCatalogue and ITypeCatalogue internal, but the integration tests currently prevent it. Options:

1. make FakeItEasy internals visible to FakeItEasy.IntegrationTests. This is easy, and I'd do it in a heartbeat, but worry that other owners have a philosophical objection.
2. move TypeCatalogueTests to FakeItEasy.Tests, but they really do feel integrationy to me, as we're actually testing what happens when the type goes out to the disk and pokes about looking for assemblies to load

Of course, I'm always keen in case someone has a better idea floating around.

[adamralph]

The term 'integration test' is so overloaded that I don't know what it means any more. For me, there are generally only two types of tests, black box and white box.

Black box tests, often called 'acceptance tests', test the public API/UI without care in the world about implementation. White box tests, AKA 'component tests' (Jez Humble) and/or 'unit tests' (a common misuse of the original term), isolate and test specific areas of the implementation.

If these integration tests are black box tests, they should not test internals, since they don't care about them. If these tests are white box tests, then they can test internals but this does in no way imply that they should test only a single class (the common misuse of the original term 'unit test').

Assuming the above to be reasonable, this raises the question of what exactly are our various test projects? My preference would be to move toward a model where we have well defined black/white box test projects. I guess the current 'specs' projects are purporting to be the former, whilst the latter is less clear. With regard to white box tests, Jez Humble makes the distinction between 'component tests' which, in the OO context, test a number of types working together and 'unit tests' (again, a misuse of the original term) which, in the OO context test a single type, isolated from all types apart from primitives and other very low level types.

Whilst typing the above it's dawned on me that our current 'integration tests' are probably acting as 'component tests' in the above classification, whilst our 'Tests' are, of course, the 'unit tests'. In that case, I think it's fine for the integration tests to have access to the internals.

😰

[blairconrad]

@adamralph, thanks for the detailed response.

I believe I agree with everything you said, and think that our IntegrationTests map onto "component tests". I will add access to the internals.

I wonder, though, if there isn't a pair of typos in one paragraph:

> If these integration tests are white box tests, they should not test internals, since they don't are about them. If these tests are black box tests, then they can test internals

(emphasis mine)

The white box tests should test the internals, no? And not for the black box. If you didn't accidentally swap these, then I begin to doubt my testing worldview.

[adamralph]

Thanks, I did indeed swap them, fixed 😁

[blairconrad]

😌

[adamralph]

Oh! #280 😊

[blairconrad]

This issue has been fixed in release 2.0.0.