RemoteTestParserConfiguration and proguard

[carlosrivin]

Hello!
We have been trying to use the RemoteTestParserConfiguration because of some parametrised tests we have.
Without running proguard it runs just fine. But I haven't been able to make it work with it. Can you give us some hints of what does the proguard configuration should look like or if there is something else that might be causing this issue?

2022-06-03T17:08:21.510+0200 [QUIET] [system.out] D 17:08:21.510 [main @coroutine#1] <c.m.m.android.adam.RemoteTestParser> Remote parsing failed. Retrying
2022-06-03T17:08:21.510+0200 [QUIET] [system.out] D 17:08:21.511 [main @coroutine#1] <c.m.m.android.adam.RemoteTestParser> Unable to parse test list using 127.0.0.1:5037:R58R6110ELH

I couldn't find any sample code for using RemoteTestParser besides the doc that is kinda simple. Is there any other doc that I can read?
Also, and maybe the issue. From the doc: "Keep in mind that instrumentationArgs should include a listener only for the test parser. " What does this mean? all we need to add is the TestAnnotationProducer right? or is there another configuration to add?
Sorry for the long post.

[Malinskiy]

Hey @carlosrivin, thanks for raising this.

I always disabled proguard for testing, not sure why you need to have it enabled, but that’s out-of-scope for this question obviously.

One thing that comes to mind is maybe TestAnnotationProducer gets obfuscated by proguard and hence fails to provide a list of tests. This can happen because technically inside test package there is nothing that references the 1st TestAnnotationProducerand it’s only specified as an argument to theam instrument`. Can you try adding the listener to the allowlist of proguard so that it keeps the class intact?

Regarding a sample - https://github.com/MarathonLabs/marathon/blob/develop/sample/android-app/Marathonfile#L22. There are several apps inside the sample directory in the codebase that you can check. I try to have most of the important functionality used there, but obviously it’s hard to use everything. You can also read the PR with the feature implementation, there are some comments there that might help.

And don’t worry about long post, it’s better to provide more context in this situation.
If you want to have better docs around this feature - I’d be happy to help merge a PR, the file that contains the docs is this one

[carlosrivin]

Thanks for the tip. I'll give it a try and study a bit more about it on Tuesday and let you know.
The reason on why we use proguard is to test as close as possible to what the consumer faces. We have a huge set of regression tests that are great for catching those nasty RuntimeExceptions caused by a proguard that was too aggressive.

[carlosrivin]

Sorry for the delay. I totally forgot to reply to you.
We have a couple of new developments in the are but I don't have the time now to investigate and understand what is going on. Maybe next week if I spend some more time on it and find something I'll update you and the thread so that more people can find the answer. But for now we are running all the tests besides the parametrised ones with local and obfuscated and those that need this params we are using the local test parser.
If I forget about this again, feel free to ping me and I'll post an update here :)