We have an android SDK (UI chat framework), and a demo application. The SDK is a submodule of the demo application and they are stored in different repositories. We had an argument with team lead. At what level is it better to write UI tests for the SDK? I say that at the SDK module level, then their launch can be embedded in CI gitlab. However, team lead claims that UI tests should be at the application level (where the SDK is connected to the repo as a link to the sub module), and no one writes UI tests in the SDK itself. Who is right?
Well, it depends. There are several different UI test approaches. For our purposes, separate widget tests and integration tests are the most applicable. I intentionally separate them, although they are implemented using the same Android instrumental testing approach.
The first thing you need to do is decide what you want to test. If it is something related to a single widget(or widget group up to a semantic page) functionality in detachment from all the other logics of the app(SDK), you should implement it inside the module where this widget is implemented. So, for example, if you want to test the behavior of some bottom sheet or segmented control, some filter page, or something of sorts, you can do it inside the SDK module itself.
If you want to test the SDK in integration with all the logic, it should perform in conjunction with the real app - you have to add tests where this integration is possible - if the first place where it is possible is the demo application - so be it.
Regarding CI flow - nothing stops you from running these tests on the demo application during the CI flow - just a little bit of extra scripting.
I would also recommend you structure your SDK in a way where all the UI logic can be defined by a non-UI element(ViewModel, Presenter, Interactor etc, with mock injection of the View interface for interaction tests) and test this non-UI element in detachment from the UI container inside the SDK module. This way, you will be able to predict the UI behavior based on the non-UI logic, making the integration(instrumental) test redundant.
So yeah, in this argument, both you and your team lead make valid points, but if you want to have only one place for all the UI testing - it is where you can use it in conjunction with the real business logic - I believe in your case it is a demo app.
Hope it helps.