Decomposition of dev/tests testsuites across corresponding modules

[bartoszkubicki]

Summary (*)

Magento 2.3 or 2.4. There are a lot of tests inside dev/tests directory, which violates modularity of platform, because while uninstalling (I mean completely removing) package from vendor tests stays in dev/tests. Wouldn't be better to spread them across corresponding modules? What if, I would like to uninstall module Magento_Wishlist and still run all integration tests? I still will have its tests in dev/tests/integration/testsuite/Magento/Wishlist, which won't work if I remove composer package with physical code.

Examples (*)

Test inside dev/tests/integration/testsuite/Magento/*.

Proposed solution

Copy-paste modules tests - I could start with integration ones into corresponding modules, so testsuite is decoupled from fixed modules set.

[m2-assistant]

Hi @bartoszkubicki. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@bartoszkubicki do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• yes
• no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[ihor-sviziev]

Related to #21465 and magento/inventory#2876, I see for MSI integration tests were already moved to the module directories.

[bartoszkubicki]

@ihor-sviziev is there a chance that PRs transporting (and by the way cleaning up formatting) is going to be accepted?

[ihor-sviziev]

AFAIK there is quite big dependency mess in the integration tests, so basically a lot of tests should be improved, this is definitely not a small part.

Fixing fixture paths could be the first step forward, similar to magento/inventory#2931. Such PR could be accepted in any patch release. But huge test refactoring - not sure if they could be accepted before 2.5.0.

[bartoszkubicki]

@ihor-sviziev my idea is not to do all job in one PR, but for example, one PR per module having a few tests - examples - Magento_AdminNotification - 5 integration tests + 1 fixture. More problematic of course will be refactoring of bigger modules like Magento_Catalog, so smaller ones would be good starting point.

[ihor-sviziev]

@bartoszkubicki personally I'm ok with it, but after migration to phpunit 9 & php7.4, just to prevent fixing a lot of conflicts and not to loose any change

[bartoszkubicki]

phpunit 9 & php7.4

For which release is this planned? I don't think, just moving classes will do any harm. By slight refactor I mean optimizing imports, nothing really changing logic of test. My proposal is to preapre small PR, for smallest module I can find - I think it is Magento_Rss - it has only one test, and we would have kind of prototype, how this migration could look like.

[ihor-sviziev]

It’s for 2.4.0, already in progress. Good idea, please create PR, we’ll see how big effort will be

…

On Tue, 28 Apr 2020 at 14:30, Bartosz Kubicki ***@***.***> wrote: phpunit 9 & php7.4 For which release is this planned? I don't think justo moving classes will do any harm. By slight refactor I mean optimizing imports, nothing really changing logic of test. My proposal is to preapre small PR, for smallest module I can find - I think it is Magento_Rss - it has only one test, and we would have kind of prototype, how this migration could look like. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28012 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOJOUMNHFFKN6QI6XDPDSLRO245RANCNFSM4MSV7XZQ> .