First paparazzi test in module takes too long time

[zhkvdm]

Description We have multimodule android project. Every module contains some different paparazzi tests. First launchable test method in first test class always takes too long time. It runs in ~20s. The next tests takes 0.5 - 2s. The same in the different modules. What's the cause of the freeze? How to speed up tests launch?

Steps to Reproduce Run paparazzi tests with multiple test methods for whole module. Use gradle task ./gradlew :feature:verifyPaparazziDebug

Additional information:

• Paparazzi Version: 1.3.4
• OS: macOS / Linux
• Compile SDK: 34
• Gradle Version: Gradle 8.9
• Android Gradle Plugin Version: 8.5.2

Screenshots Test reports: 1

2

[geoff-powell]

Do you mind providing a sample project that reproduces the issue?

[zhkvdm]

Do you mind providing a sample project that reproduces the issue?

I can't share this project, it's prohibited. But I can try to reproduce this issue at sample project

[jrodbx]

First launchable test method in first test class always takes too long time. It runs in ~20s. The next tests takes 0.5 - 2s. The same in the different modules. What's the cause of the freeze? How to speed up tests launch?

The first test bootstraps Layoutlib via Bridge.init and statically caches it for subsequent runs, which explain why you notice a drop after the first test.

However, ~20s is high and I've never seen this before. I suspect you may just be running the tests with a conservative heap size; if so, bumping the max heap size should be enough to fix this.

[zhkvdm]

First launchable test method in first test class always takes too long time. It runs in ~20s. The next tests takes 0.5 - 2s. The same in the different modules. What's the cause of the freeze? How to speed up tests launch?

The first test bootstraps Layoutlib via Bridge.init and statically caches it for subsequent runs, which explain why you notice a drop after the first test.

However, ~20s is high and I've never seen this before. I suspect you may just be running the tests with a conservative heap size; if so, bumping the max heap size should be enough to fix this.

Okay, thanks for reply. Is it possible to cache and share Layoutlib between all modules? Now each module init Layoutlib when running tests.

[jrodbx]

Is it possible to cache and share Layoutlib between all modules?

This is a Gradle design issue. Each module has its own test task, which I believe runs in its own process via the test runner. If I'm understanding this correctly, then the answer to your question would be "no".

What's your current CI heap size? Have you tried increasing it?

[zhkvdm]

Is it possible to cache and share Layoutlib between all modules?

This is a Gradle design issue. Each module has its own test task, which I believe runs in its own process via the test runner. If I'm understanding this correctly, then the answer to your question would be "no".

What's your current CI heap size? Have you tried increasing it?

We run tests in docker container with params --memory=42g --cpus="8" Xmx25

[zhkvdm]

I have tried an android screenshot testing (https://developer.android.com/studio/preview/compose-screenshot-testing). It works faster than paparazzi, but it should use the same mechanics, I think.

[zhkvdm]

I have created a new empty project with 2 screens and 6 paparazzi tests. The test takes 3s on initialization. Is it ok?

[nick2525]

@jrodbx I posted a proposal to gradle https://github.com/gradle/gradle/issues/31332 so that there is a way to bypass this restriction

[nick2525]

Gradle recommend to use build services https://docs.gradle.org/current/userguide/build_services.html