[MGNLTEST-34] Clean-up packages for int.- and ui-tests on CE, dx-core Created: 15/Jan/20  Updated: 16/Mar/21  Resolved: 16/Mar/21

Status: Closed
Project: Magnolia Test Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Christoph Meier Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: QA&Testing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLTEST-1 Attempt to extract the integration te... Closed
relates to MGNLTEST-28 Run selftests on extracted test frame... Closed
relation
is related to MGNLTEST-30 Separate (sub)module for the test-fra... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Epic Link: core-TF-features-bugs-improvements

 Description   

This ticket has been created to "save" some valuable comments given on a PR.

The main idea is to make it easy to distinguish:

  • Where to put classes for UI- or Integration-tests 
    • when using the "old" ui-test-framework 
    • when using the "new" ui-test-framework
  • Separating the framework from the tests

 

I add the contents of the comments to the comments section.  Otherwise this description get too big. But here are the links to the comments: (Not sure whether they will survive)

 

Note that this is highly related to / with DEV-1348.
We may consider tackle them both together.

 

 



 Comments   
Comment by Christoph Meier [ 15/Jan/20 ]

This comment is a copy of a comment from a PR on bitbucket.

 


TL;DR Preliminary suggestion:
integrationtests -> integrationtests.deprecated
testframework OK
functionaltests -> integrationtests / seleniumtests / ui-test (since ui-test is a superset for functional, integration and ui-tests. Or actually, will we build integration tests w/o clicking via Selenium?).

Thanks for explaining this thoroughly.

Bad names may not seem important here if you have been navigating the packages and modules for a long time - you have a clear mental mapping of what is what and know how to move around those. It may subjectively feel like a non-issue since the mental mapping works fine for you. But for me (and possibly anyone new to this) it's a source of confusion and it requires digging, asking and creating the mental mapping afterwards for one self. Which fades if the packages are not sth one interacts with on daily basis.

We want to avoid everyone asking the same questions like:

  • "am I to expect a different type (functional/integration) of tests here than there?"
  • "Which is deprecated/obsolete?"
  • "Which is new?"
  • "Where do I put my tests"?
    If someone does not know there was a transition from some old framework to a new framework, the packages won't help to figure this out at all.

The naming should be refined now and made clear, ideally by those, who have a good understanding of what makes them distinct.
If "old" and "new" is to be avoided, we can name "old" as "obsolete" or "deprecated", which is a common way to make ppl aware development is elsewhere.


Source: https://git.magnolia-cms.com/projects/PLATFORM/repos/ce/pull-requests/206/overview?commentId=44564 (from sdemocko)

Generated at Mon Feb 12 07:44:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.