<#CGN6QTTFE|testing> We are writing integration te...
# android
v
#testing We are writing integration tests (UI + ViewModel + Repository + DB) for our app.We dont have unit tests for our app yet. We have to mock/fake the Network part with Fake Implementations. if we do like that, the network layer will be untested. So, my team found another solution as instead of fake/mocking the entire network layer, add an interceptor in the retrofit client and to pass the network response json. I think this will become more hard to maintain the future. But i don't have strong enough points to convince my team to use fakes/mocks instead of adding an interceptor and passing json strings. Which is the better way in this situation and why? please provide your suggestions.
not kotlin but kotlin colored 2
j
The first thing you need to clarify with your team is whether the tests they want to write are even unit tests at this point because when you start testing business logic along with the data layer, you're no longer dealing with pure unit tests. Unit tests should ideally isolate and test a single unit of code in complete isolation from external dependencies like the network or databases. What you're describing your team wants to achieve is more akin to integration testing. Personally I would mock outer dependencies when writing a "Unit Test". Even if your team members are adamant of testing the data layer, intercepting network calls and injecting JSON responses will quickly become unwieldy, especially as your app's API surface grows. Managing these JSON payloads across multiple tests can lead to duplication, which will only make it harder to maintain and update when the API changes. Additionally, if your team ever needs to test edge cases or error scenarios, crafting the right JSON responses for each scenario will be a headache. If your team still prefers the interceptor approach for now, you could suggest setting up a dedicated module or utility class to manage the JSON payloads centrally. This way, you can at least contain the complexity and make it easier to update or replace the payloads in the future. Nvm, I just saw that you peeps are indeed writing integration tests and not unit tests in which case I am with what your team has decided. Mocking a certain section of the code defies what integration tests are set to achieve.
👍 1
v
But in the E2E test the network layer will be covered right? Also, if we write fake implementations it will be like one time implementations and it will change when the data layer behavior changes.. if we do pass json, eventhough the data layer does not change we may need to ready the json right...?so can't we just ignore network layer in integration testing safely...? What do u think?