Ignore lib/internal/Magento/Framework/App/Test/Unit/_files/app/etc/en…

[hostep]

…v.php that gets generated by running unit tests

Description (*)

When running Magento Framework unit tests on your local, one of the tests (don't ask me which one) generates a file: lib/internal/Magento/Framework/App/Test/Unit/_files/app/etc/env.php
So I think we should ignore this file in git.

Related Pull Requests

Fixed Issues (if relevant)

None

Manual testing scenarios (*)

1. Clone this repo
2. Check that your git status isn't dirty
3. Run vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist lib/internal/Magento/Framework/
4. When it's finished, check your git status again
5. Expected is that it's still not dirty, but before this PR, it will show a new file found: lib/internal/Magento/Framework/App/Test/Unit/_files/app/etc/env.php

Questions or comments

In my opinion, it's not needed to run automatic tests on this PR, as it shouldn't affect anything besides local developer experience...

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

Resolved issues:

1. resolves [Issue] Ignore lib/internal/Magento/Framework/App/Test/Unit/_files/app/etc/en… #39304: Ignore lib/internal/Magento/Framework/App/Test/Unit/_files/app/etc/en…

[m2-assistant]

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

Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ 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.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

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.

[ihor-sviziev]

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

[hostep]

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

[hostep]

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

magento2/lib/internal/Magento/Framework/App/Test/Unit/ObjectManagerFactoryTest.php

Lines 46 to 53 in adc4105

	public function testCreateObjectManagerFactoryCouldBeOverridden()
	{
	$this->expectException('BadMethodCallException');
	$this->expectExceptionMessage('Magento\Framework\App\Test\Unit\ObjectManager\FactoryStub::__construct');
	$rootPath = __DIR__ . '/_files/';
	$factory = Bootstrap::createObjectManagerFactory($rootPath, []);
	$factory->create([], false);
	}

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.

[hostep]

@magento run all tests

[magento-automated-testing]

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.

[ihor-sviziev]

@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

[engcom-Dash]

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

[engcom-Dash]

@magento run all tests

[hostep]

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).

[hostep]

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)

[hostep]

@magento run Static Tests, Unit Tests

[engcom-Dash]

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

[engcom-Dash]

@magento run Functional Tests B2B

[engcom-Dash]

The Functional B2B test failures are different in recent 2 successive builds with a known issue. 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/

[engcom-Dash]

@magento create issue