Decouple Chucker from Android

⚠️ Is your feature request related to a problem? Please describe

I don’t like that ChuckerInterceptor is coupled with the Android framework. It restricts it and makes testing harder. The need for doing that in tests makes me sad.

https://github.com/ChuckerTeam/chucker/blob/d919874d602733da1c90ceea1a658d69ea242036/library/src/test/java/com/chuckerteam/chucker/ChuckerInterceptorDelegate.kt#L26-L33

💡 Describe the solution you’d like

Right now this is a primary constructor.

https://github.com/ChuckerTeam/chucker/blob/d919874d602733da1c90ceea1a658d69ea242036/library/src/main/java/com/chuckerteam/chucker/api/ChuckerInterceptor.kt#L39-L45

I’d like to change it and introduce some internal interfaces for i.e. providing resource strings or collecting requests/responses. These interfaces would have implementations based on Context that would be used from a secondary constructor that accepts an instance of Context.

📊 Describe alternatives you’ve considered

It does not solve the whole problem but some testing issues could be solved by running instrumented tests. I don’t think it should be done as the only step and I’d like to make the main proposal happen. However, it would be also good to run instrumented tests with the real scenario setup (I can create a separate issue for this).

📄 Additional context

This is for Chucker 4.x.

🙋 Do you want to develop this feature yourself?

• Yes
• No

[cortinico]

Having interfaces would enable to test fake implementations against real ones and using former in tests of ChuckerInterceptor. If in your opinion it does not bring much value I don’t have any real need to pursue this. 😃

I think we should really work in this direction.

Imho the title of this issue is a bit misleading as “Decouple Chucker from Android” is really out of the scope of this library (we provide a debugging tool for Android, so we need to depend on the framework).

From my point of view we should evolve our API (for 4.x in this direction):

1. Keep on having a ChuckerInterceptor(Context) constructor (i.e. our primary constructor with default values). Applying our library should as easy as that. It’s reasonable to ask for a Context to our users as we’re showing UI/Notifications, etc.
2. Have all the Android related code inside the ChuckerCollector. That’s going to be the connection point between our library and the Android framework
3. Ideally extracting ChuckerCollector to an interface to better define the interaction between collector/interceptor and for better testability
4. Ideally the ChuckerInterceptor should delegate all the implementation to a pure java class that interacts with this extracted interface.

This makes code for us easier to maintain and test.

As a side note, for the sake of testing we should probably work on extracting all the processResponseBody, processRequest methods inside the ChuckerInterceptor to separate classes and test them in isolation. This is something we can start doing today. It won’t fix the overall issue as you still have to mock a ChuckerCollector that needs a Context, but we can keep it as an iterative process and further improve once we extract an interface out of it.

[MiSikora]

Well, yes. My main motivation are tests. However, not for tests sake but for making the code more testable. Having interfaces would enable to test fake implementations against real ones and using former in tests of ChuckerInterceptor. If in your opinion it does not bring much value I don’t have any real need to pursue this. 😃