Hi @hostep. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

@hostep maybe better to add file removal at the end of that test?

Yeah I though of that as well, do you know which test(s) is/are responsible for generating that file?

@ihor-sviziev: I've found the test that generated the file (somehow):

So instead of ignoring that generated file, I'm now removing it like you suggested.

However, and this is strange, that particular test fails on my local. I've seen it fail before a couple days ago as well, but ignored it, because I assumed something was wrong with my local environment or so, but now I'm beginning to doubt that all of the Unit Tests which are part of the codebase are actually being executed by the automation here on github.
Is there some kind of overview to see which Unit Tests are being ignored or which ones are actually being executed by the automated test system?
Because I have a total of 9 failures on my local when trying to execute the Unit Tests from the Magento framework:

$ vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist lib/internal/Magento/Framework/

...

1) Magento\Framework\App\Test\Unit\ObjectManagerFactoryTest::testCreateObjectManagerFactoryCouldBeOverridden
Failed asserting that exception of type "BadMethodCallException" is thrown.

2) Magento\Framework\Config\Test\Unit\XsdTest::testInvalidXmlFile with data set #0 ('view.xsd', 'view_invalid.xml', 8)
Failed asserting that 9 matches expected 8.

lib/internal/Magento/Framework/Config/Test/Unit/XsdTest.php:38

3) Magento\Framework\Stdlib\Test\Unit\DateTime\DateTimeFormatterTest::testFormatObjectNumericFormat with data set #0 (null, 'Mar 30, 2022, 12:01:02 AM')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'Mar 30, 2022, 12:01:02 AM'
+'Mar 30, 2022, 12:01:02 AM'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/DateTimeFormatterTest.php:165

4) Magento\Framework\Stdlib\Test\Unit\DateTime\DateTimeFormatterTest::testFormatObjectNumericFormat with data set #1 (-1, '12:01:02 AM Greenwich Mean Time')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'12:01:02 AM Greenwich Mean Time'
+'12:01:02 AM Greenwich Mean Time'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/DateTimeFormatterTest.php:165

5) Magento\Framework\Stdlib\Test\Unit\DateTime\DateTimeFormatterTest::testFormatObjectNumericFormat with data set #2 (3, '3/30/22, 12:01:02 AM Greenwic...n Time')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'3/30/22, 12:01:02 AM Greenwich Mean Time'
+'3/30/22, 12:01:02 AM Greenwich Mean Time'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/DateTimeFormatterTest.php:165

6) Magento\Framework\Stdlib\Test\Unit\DateTime\DateTimeFormatterTest::testFormatObjectNumericFormat with data set #3 (2, 'Mar 30, 2022, 12:01:02 AM Gre...n Time')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'Mar 30, 2022, 12:01:02 AM Greenwich Mean Time'
+'Mar 30, 2022, 12:01:02 AM Greenwich Mean Time'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/DateTimeFormatterTest.php:165

7) Magento\Framework\Stdlib\Test\Unit\DateTime\DateTimeFormatterTest::testFormatObjectNumericFormat with data set #4 (1, 'March 30, 2022 at 12:01:02 AM...n Time')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'March 30, 2022 at 12:01:02 AM Greenwich Mean Time'
+'March 30, 2022 at 12:01:02 AM Greenwich Mean Time'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/DateTimeFormatterTest.php:165

8) Magento\Framework\Stdlib\Test\Unit\DateTime\DateTimeFormatterTest::testFormatObjectNumericFormat with data set #5 (0, 'Wednesday, March 30, 2022 at ...n Time')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'Wednesday, March 30, 2022 at 12:01:02 AM Greenwich Mean Time'
+'Wednesday, March 30, 2022 at 12:01:02 AM Greenwich Mean Time'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/DateTimeFormatterTest.php:165

9) Magento\Framework\Stdlib\Test\Unit\DateTime\TimezoneTest::testGetDatetimeFormat with data set #0 ('en_US', 3, 'M/d/yy h:mm a')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'M/d/yy h:mm a'
+'M/d/yy h:mm a'

lib/internal/Magento/Framework/Stdlib/Test/Unit/DateTime/TimezoneTest.php:213

(those failures of the dates, are always around a "special" whitespace character:   (the U+202F - NARROW NO-BREAK SPACE character) which appears in the "actual" output, but not in the "expected" output)

For example, the failure in the Magento\Framework\Config\Test\Unit\XsdTest::testInvalidXmlFile test is correct, it should be expected a total of 9 errors and not 8, so to me it feels like some of these tests are not executed whatsoever?

So if some of these tests are maybe never executed, maybe we should instead remove them entirely instead of trying to fix them?
Is there anybody we can contact to try to figure this out? Before we spend too much time on fixing something that doesn't need to be fixed.

@magento run all tests

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

@hostep we raised this question multiple times, but AFAIK didn't get some meaningful answer of how it's getting executed. It just somehow works on Adobe infrastructure.
#24463 #23259 #21001 #34733

Hi @hostep ,

Thanks for the collaboration & contribution!

✔️ QA Passed
Preconditions:

Install fresh Magento 2.4-develop
Steps to reproduce

• As per the description

Before: ✖️

After: ✔️

Builds are failed. Hence, moving this PR to Extended Testing.

Thanks

@magento run all tests

Please don't push new changes here, until I've figured out the static test failure around new copyright requirement introduced in your coding-standards v35, first want to discuss this on Slack because I believe the requirement is not implemented correctly (should only apply to new files, not to old/existing files).

Updated the copyright header after talking with Stanislav on Slack, copyright header should now look like this for all source files according to the Adobe legal team:

Copyright [year code created] Adobe
All Rights Reserved.

Just for sake of moving this PR forwards I've updated it, but I still believe the requirements are incorrect, my reasoning (but I'm not a lawyer):

• old files should just keep the current copyright, new files should indeed use the new required copyright header
• Adobe acquired Magento in 2018, so each file created before the acquisition shouldn't mention Adobe, unless a big portion of the file was rewritten after 2018
• having to change the copyright header in each file touched by a PR is just unneeded noise, which will make comparisons between different Magento versions way too noisy and harder to find "real" changes
• ...

@magento run Static Tests, Unit Tests
(there is no need to run any other test, none of the other test suite results will be affected by this change)

@magento run Static Tests, Unit Tests

@magento run WebAPI Tests, Semantic Version Checker, Database Compare, Functional Tests B2B, Functional Tests CE, Functional Tests EE, Integration Tests, Magento Health Index,

@magento run Functional Tests B2B

The Functional B2B test failures are different in recent 2 successive builds. They neither part of PR nor failing because of the PR changes, hence moving it to Merge in Progress.

Run 1: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/37631/1c5fdf3d5dbf12bd0bb93e669cd36093/Functional/allure-report-b2b/index.html#categories/7441e147742cc9294f4ce2a0b5090c42/4fda682efb5abfa2/

Run 2: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/37631/e9dbdb66cc0f20bac53146a3d1ef96bc/Functional/allure-report-b2b/index.html#categories/39002bb4b823f2d59e22404a186a7115/544295773acd815e/

@magento create issue