Reuse frontend build from tests

[alexkolson]

Feature idea

Currently if you have quinoa run your tests, it builds your frontend twice, once for tests, and then once later in the quarkus:build phase. It would save quite a lot of time if the build that was done to run the tests could be re-used in the quarkus:build step so that builds are slightly faster. I'm not sure it's possible, but I thought I'd ask anyway. If it can't be done or you would not like to do this, I totally understand! Maybe there's even a way I can do this as a user of quinoa already and I just haven't looked hard enough? Either way, thanks in advance!

[ia3andy]

That's a good idea. I haven't implemented it yet because even if the build-dir already exists it's hard to predict when it should or shouldn't be rebuilt.

@geoand @aloubyansky do we have some kind of build id (to find out if we are in the same build/test sequence)?

[geoand]

We do not AFAIK

[ia3andy]

We do not AFAIK

Would it make sense to introduce it?

[geoand]

It hasn't been necessary so far, so it's hard to say

[aloubyansky]

Prod and test resources may have differences. It might be tricky to evaluate whether an existing build outcome can be re-used as the outcome of the subsequent build.

[alexkolson]

I totally agree that is a tricky issue but I would still suggest that it would be a useful feature. Especially for things like playwright tests in combination with continuous testing, where the package.json build command gets re-run for each test run.

[alexkolson]

To simplify things (maybe) the first version could perhaps just be a property like quarkus.quinoa.build-frontend-once-for-tests=true (better naming needed of course).

[ia3andy]

I agree this is a pain!

What we could do is to generate some kind of hash based on the webui directory and store it in the quinoa build directory, this could be enabled through configuration.

[edeandrea]

I'm running into this as well, and its frustrating because the Quinoa build takes a while. If I have more than one test class with @TestProfile(QuinoaTestProfiles.Enable.class) then that seems to have quarkus kill the app, rebuild, and restart between test classes.

In Quarkus couldn't we instead group test execution by test classes that have the same @TestProfile, and then keep the same app instance up between those test classes?

We already do something like that for @QuarkusTestResource don't we?

@geoand / @aloubyansky ?

[ia3andy]

@edeandrea test are not using the dev mode, it builds the app.

We could have a similar option to what @alexkolson suggested and have a specific target directory for test and not re-build if already there, but I think we need a way to clean it automatically.

[edeandrea]

But when running the tests the app seems to be rebuilt between test class execution (I have logs that I can show that it does). The app is shut down, the rebuild happens, and then the app restarts.

I have exactly the same use case as @alexkolson - a bunch of test classes that use Playwright to test various pages in a react app.

When my tests execute, it would be nice if the app just stayed up in between test class execution. I'm not talking about dev mode.

I can solve this by only having a single test class that has

@QuarkusTest
@TestProfile(QuinoaTestProfiles.Enable.class)
@WithPlaywright

and then have @Nested classes within, each nested class representing one of my page tests. That works, but it makes my test class really big (thousands of lines). I'd rather keep my test classes separated (one test class per page being tested).

I actually see this more of a generic Quarkus issue than a Quinoa issue. I can observe similar behavior if I remove Quinoa and just create my own custom QuarkusTestProfile and then have multiple test classes that use @TestProfile(MyTestProfile.class). Can't Quarkus be smart enough to organize test execution so that all test classes that use the same @TestProfile share the same app instance and don't require a rebuild?

[geoand]

We already do something like that for @QuarkusTestResource don't we?

Indeed