phpunit long tests speedup

[orthagh]

The idea was to generate a junit xml report to identify slow tests and try to optimize to top 5 slowest tests. Only 2 had optimization possible:

Summary:

1. OpenAPIGenerator Optimization 73831d5

locally 155s -> 4s (97%)

• File: OpenAPIGenerator.php
• Change: Implemented static caching for getComponentSchemas. This method was previously called multiple times during schema generation and resolution, leading to redundant calculations.
• Impact: Reduced OpenAPIGeneratorTest execution time from 155s to 4s.

2. Optimization of testSearchAllMeta fe27e37

locally 111s -> 13s (88%)
The testSearchAllMeta test in tests/functional/SearchTest.php currently performs redundant searches by testing every search option of every meta-itemtype for every base itemtype. Since the JOIN logic between a base and a meta itemtype is independent of the specific search option chosen from the meta itemtype, we can significantly reduce the number of doSearch calls.

[orthagh]

Ok, I think I will no go further, I can't find more optimization that are really impactful.
OpenAPIGenerator part is straightfoward.
for testSearchAllMeta, I take your opinion @cedric-anne, it's a massive gain, but original purpose was to test everything. It now skip every joined searchoptions that are already has been tested once with another itemtype, and keep only the first SO for any following itemtypes.

[Copilot]

Pull request overview

This PR optimizes PHPUnit test performance by reducing execution time for two of the slowest tests through intelligent caching and redundancy elimination.

• Implements static caching in OpenAPIGenerator to avoid redundant schema generation calls
• Optimizes SearchTest to skip redundant meta-itemtype search option testing while maintaining coverage

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Glpi/Api/HL/OpenAPIGenerator.php	Adds static caching to getComponentSchemas method, reducing execution time from 155s to 4s by avoiding redundant schema calculations
tests/functional/SearchTest.php	Optimizes testSearchAllMeta by tracking fully-tested meta-itemtypes and skipping redundant search option tests, reducing execution time from 111s to 13s while maintaining test coverage

[Copilot]

The static cache in getComponentSchemas may return stale data if the list of controllers changes between calls (e.g., when plugins are enabled/disabled during tests). The cache is keyed only by api_version but the method depends on Router::getInstance()->getControllers() which can vary based on the application state. Consider adding the controllers state to the cache key or implementing a cache invalidation mechanism when the router state changes.

[cconard96]

The bot is technically correct (the best kind of correct) and I think it is why there isn't much caching currently here. There are other cases that may fail like if a new custom asset definition is added during the tests, or if permissions change, and therefore the available schemas change.

I think the preferred way to handle per-request caching is a private property on the class and a method to allow clearing it as needed on a test-by-test basis.

[orthagh]

Var has been moved to a private property, and a method to clean cache added.
I have no clue if the method is already needed in the tests' suite that said

[cconard96]

Ok, I think I will no go further, I can't find more optimization that are really impactful. OpenAPIGenerator part is straightfoward. for testSearchAllMeta, I take your opinion @cedric-anne, it's a massive gain, but original purpose was to test everything. It now skip every joined searchoptions that are already has been tested once with another itemtype, and keep only the first SO for any following itemtypes.

I'm not sure it can be 100% certain that the joins will not change for a meta itemtype based on the searched itemtype currently or in the future.
There are a lot of special cases in Glpi/Search/Provider/SQLProvider::getMetaLeftJoinCriteria.

[cedric-anne]

Ok, I think I will no go further, I can't find more optimization that are really impactful. OpenAPIGenerator part is straightfoward. for testSearchAllMeta, I take your opinion @cedric-anne, it's a massive gain, but original purpose was to test everything. It now skip every joined searchoptions that are already has been tested once with another itemtype, and keep only the first SO for any following itemtypes.

I'm not sure it can be 100% certain that the joins will not change for a meta itemtype based on the searched itemtype currently or in the future. There are a lot of special cases in Glpi/Search/Provider/SQLProvider::getMetaLeftJoinCriteria.

When I introduced this test, the main issues here were:

1. lack of alias in joined table, and this will still be tested with a search on the first criterion;
2. conflict on aliases, and this is done later in the test.

Therefore, I think the proposed change is OK.