Make classes extensible.

[rafalwrzeszcz]

Entire SDK is completely locked (full of package-private members). Would be good I think, to expose some of the properties either via protected properties, so that it can be extended, or make sure to provide accessors, so that it can be mocked.

I'm talking mainly about testing purposes.

One example is CDAClient.service property. Accessed directly withing package. So mocking client itself is pointless as all of the logic accesses directly the service (not via getter, which could be mocked).

Another example are model classes (CDAEntry, CDAResource etc.) which only rely on artifical accesses through de-serialization. I think they should provide at least constructors allowing for passing initial values.

[mariobodemann]

Hey,

the purpose of not having fields exposed, is due to the fact, that we don't want changes to the fields happening outside of the defined paths: Builders and Serialisation.

In our own tests, we are creating a client and injecting a url to a mocked server, this could be a way for you too, providing a JSON and injecting it into the test. Alternatively you can use the builder of the client to set a custom call factory, controlling what should be returned from the potentially fake network.

Alternatively you could use an adapter to encapsulate Contentful and mock the adapter instead.

And lastly, since the fields are mostly package private, you could move your tests into the same package, if you really need to access the internals.

I hope some of the ideas are helpful, and please feel free to reach out to us again ...

[rafalwrzeszcz]

The thing is that I don't want to involve entire client-server communication in the unit test of data model handling (mapping data types etc.), this is not how unit tests are working. I don't want to test Contentful client - I believe it works properly, I want to mock the data models.

CDAClient returns CDAEntry (or other CDA~ classes), this is the point that interests me, not the internal server calls.

[rafalwrzeszcz]

One more case, maybe not for extensibility, but availability are webhooks. When Contentful sends webhook notification to URL with a data structure, it's tedious to deserialize it on our own, when we have a Contetful SDK in place with all of the data structure and GSON deserializer, but sealed and not usable from outside.

[mariobodemann]

Thanks again for the feedback.

We'll keep that in mind and think about how and what we can do to improve the situation.

[mariobodemann]

Closing this issue for now, reiterating on it if needed on this issue or on a new one is recommended if needed.

[nuvan]

Hi @rafalwrzeszcz ! What strategy did you take to test then ( if you can still remember :D )?
We are with the same issue with our tests.

[rafalwrzeszcz]

Hi @rafalwrzeszcz ! What strategy did you take to test then ( if you can still remember :D )? We are with the same issue with our tests.

Since in our webhooks we are not interested in full payload we just wrote custom JSON stream deserializers, not worrying about full data structure. Far from perfect and very specific case.