Make it easier to run performance tests locally

It seems that ddev get is deprecated, but it still works:

drupal_cms$ ddev get ddev/ddev-selenium-standalone-chrome
Command "get" is deprecated, use 'ddev add-on get' instead
Installing ddev/ddev-selenium-standalone-chrome:1.1.0
1.1.0_1694058897.tar.gz 4.53 KiB / ? [--------------------------------------------------------------------------------------------------------------------=----------------------]  46.43% 0s 

Installing project-level components:
👍 docker-compose.selenium-chrome.yaml
👍 config.selenium-standalone-chrome.yaml

Installed DDEV add-on ddev/ddev-selenium-standalone-chrome, use `ddev restart` to enable.
Please read instructions for this add-on at the source repo at
https://github.com/ddev/ddev-selenium-standalone-chrome
Please file issues and create pull requests there to improve it.
Installed ddev-selenium-standalone-chrome:1.1.0 from ddev/ddev-selenium-standalone-chrome

After that, I did git add .ddev and git commit in order to create the MR here.

After doing that, and after switching to the feature branch, you need ddev restart in order to see the additional containers:

drupal_cms$ ddev restart
Restarting project drupal-cms-dev... 
...
Restarted drupal-cms-dev 
Your project can be reached at https://drupal-cms-dev.ddev.site
See 'ddev describe' for alternate URLs. 

drupal_cms$ ddev describe
 Project: drupal-cms-dev ~/repos/drupal_cms https://drupal-cms-dev.ddev.site                                          
 Docker platform: linux-docker                                                                                        
 Router: traefik                                                                                                      
 SERVICE       STAT  URL/PORT                                                                      INFO               
 web           OK    https://drupal-cms-dev.ddev.site                                              drupal11 PHP8.3    
                     InDocker -> Host:                                                             nginx-fpm          
                      - web:80 -> 127.0.0.1:32828                                                  docroot:'web'      
                      - web:443 -> 127.0.0.1:32827                                                 Perf mode: none    
                      - web:8025                                                                   NodeJS:22          
 db            OK    InDocker -> Host:                                                             mariadb:10.11      
                      - db:3306 -> 127.0.0.1:32826                                                 User/Pass: 'db/db' 
                                                                                                   or 'root/root'     
 selenium-chr  OK    https://drupal-cms-dev.ddev.site:7900                                                            
 ome                 InDocker:                                                                                        
                      - selenium-chrome:4444                                                                          
                      - selenium-chrome:5900                                                                          
                      - selenium-chrome:7900                                                                          
 Mailpit             Mailpit: https://drupal-cms-dev.ddev.site:8026                                                   
                     Launch: ddev mailpit                                                                             
 Project URLs        https://drupal-cms-dev.ddev.site, https://127.0.0.1:32827,                                       
                     http://drupal-cms-dev.ddev.site, http://127.0.0.1:32828                                          
 

I think that is all we need, but I am not sure what the next steps are. Where are the performance tests?

There's only one performance test; I think it's in recipes/drupal_cms_starter/tests/src/FunctionalJavascript. Are you able to run it? You probably need to update .ddev/config.yml to set the MINK_DRIVER_ARGS_WEBDRIVER environment variable.

I tested by removing the DDEV containers and everything not tracked by Git:

ddev stop # probably redundant
ddev delete -O
git clean -dfx
rm -rf web/modules/contrib/experience_builder
git clean -dfx

I guess I should not be surprised that XB is special. Then ddev start and ddev describe. It all looks good: there is a selenium-chrome container as in my previous comment.

I am not sure whether the test is slow or if it is hanging:

drupal_cms$ ddev exec phpunit -c web/core/phpunit.xml.dist recipes/drupal_cms_starter/tests/src/FunctionalJavaScript/PerformanceTest.php
PHPUnit 10.5.40 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.3.14
Configuration: /var/www/html/web/core/phpunit.xml.dist

(no further output yet).

It's a very slow test.

Good news: the test was slow, or I was impatient:

PHPUnit 10.5.40 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.3.14
Configuration: /var/www/html/web/core/phpunit.xml.dist

D                                                                   1 / 1 (100%)

HTML output was generated.
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-1-52365397.html
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-2-52365397.html
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-3-52365397.html
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-4-52365397.html
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-5-52365397.html
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-6-52365397.html
https://drupal-cms-dev.ddev.site/sites/simpletest/browser_output/Drupal_Tests_drupal_cms_starter_FunctionalJavascript_PerformanceTest-7-52365397.html


Time: 03:39.369, Memory: 10.00 MB

1 test triggered 4 deprecations:

1) /var/www/html/vendor/symfony/error-handler/DebugClassLoader.php:341
The "Drupal\easy_breadcrumb\EasyBreadcrumbBuilder::applies()" method will require a new "\Drupal\Core\Cache\CacheableMetadata $cacheable_metadata" argument in the next major version of its interface "Drupal\Core\Breadcrumb\BreadcrumbBuilderInterface", not defining it is deprecated.

Triggered by:

* Drupal\Tests\drupal_cms_starter\FunctionalJavascript\PerformanceTest::testPerformance
  /var/www/html/recipes/drupal_cms_starter/tests/src/FunctionalJavaScript/PerformanceTest.php:32

2) /var/www/html/vendor/symfony/error-handler/DebugClassLoader.php:341
Method "Symfony\Component\EventDispatcher\EventSubscriberInterface::getSubscribedEvents()" might add "array" as a native return type declaration in the future. Do the same in implementation "Drupal\autosave_form\EventSubscriber\ConfigSubscriber" now to avoid errors or add an explicit @return annotation to suppress this message.

Triggered by:

* Drupal\Tests\drupal_cms_starter\FunctionalJavascript\PerformanceTest::testPerformance
  /var/www/html/recipes/drupal_cms_starter/tests/src/FunctionalJavaScript/PerformanceTest.php:32

3) /var/www/html/vendor/symfony/error-handler/DebugClassLoader.php:341
Method "Symfony\Component\EventDispatcher\EventSubscriberInterface::getSubscribedEvents()" might add "array" as a native return type declaration in the future. Do the same in implementation "Drupal\focal_point\EventSubscriber\MigrationSubscriber" now to avoid errors or add an explicit @return annotation to suppress this message.

Triggered by:

* Drupal\Tests\drupal_cms_starter\FunctionalJavascript\PerformanceTest::testPerformance
  /var/www/html/recipes/drupal_cms_starter/tests/src/FunctionalJavaScript/PerformanceTest.php:32

4) /var/www/html/vendor/symfony/error-handler/DebugClassLoader.php:341
Method "IteratorAggregate::getIterator()" might add "\Traversable" as a native return type declaration in the future. Do the same in implementation "Drupal\crop\Entity\CropType" now to avoid errors or add an explicit @return annotation to suppress this message.

Triggered by:

* Drupal\Tests\drupal_cms_starter\FunctionalJavascript\PerformanceTest::testPerformance
  /var/www/html/recipes/drupal_cms_starter/tests/src/FunctionalJavaScript/PerformanceTest.php:32

OK, but there were issues!
Tests: 1, Assertions: 27, Deprecations: 4.

I don't think any of this looks wrong!

We are currently in feature freeze, which means we are only committing bug fixes. So although this is RTBC, it needs to wait until after release to be committed. Because this is only affecting internal infrastructure, and makes no changes to the Drupal CMS product itself, I think it's fine to commit to both 1.x and 1.0.x.

This will help with running any functional js tests that might be added in the future, not just performance tests (although I don't think there are any yet).

Committing the results of ddev add-on get doesn't seem right, there ought to be a way to specify it as a dependency somehow - unfortunately I don't know what that is, but we could ask @rfay maybe? Otherwise Drupal CMS will have to keep updating these files when they get out of sync (or end up with hard to debug issues because they haven't kept in sync).

I can open a follow-up to add gander support too (the grafana performance dashboard), but per above would prefer it if we could add it as a dependency rather than committing all the files.

+1 for asking @rfay, but I'm not seeing anything in the DDEV documentation that says don't commit the add-ons. Best I can figure, we are supposed to commit the add-ons, and update them when we feel like (and presumably commit those updates).

Asked in slack https://drupal.slack.com/archives/C5TQRQZRR/p1736691743374349

Yeah if this is the way it seems fine, but feels like theoretically there might be a place to say 'pull in this addon' that would then be a 1-5 liner.

phenaproxima → credited rfay → .

From @rfay in Slack:

Our usual recommendation for teams is to commit the add-on if you need it.

With that sign-off in hand, restoring RTBC.

This looks just right to me. Note that when add-ons change, or an update is needed, somebody needs to do an MR with the change.

Thanks for confirming!

With Drupal CMS having launched, I think it will be very beneficial to development to have local performance testing from here on out. So, merged into 1.x. Since this only affects internal development infrastructure and is never distributed to end users, cherry-picked to 1.0.x as well. Thanks!