Write tests

Add test about #2973972: Integration with jsonapi_extras .

As entity share requires to have two different Drupal sites to work, for the automated tests there is two solutions, either:

• mock what is needed for the different features of entity share to be able to emulate another websites requests or responses,
• be able to have a CI environment that provides two Drupal sites.

Features :

1: generation of endpoint /entity_share, check if:

• the channels URLs are valid
• filters
• groups of filters
• sorts
• multilingual

As this feature requires only entity_share_server, there is no need of a second website. So not concerned by the difficulty to setup test environment.

2: pull content entities:

• field types:
  • Boolean
  • Content (entity reference)
  • Comment: currently not supported
  • Date:
    • date and time
    • date only
  • Dynamic entity reference: currently not supported
  • Email
  • File
  • Image
  • Link:
    • internal (with JSON:API Extras field enhancers at this moment)
    • external
  • List:
    • float
    • integer
    • text
  • Media:
    • audio
    • image
    • file
    • remote video
    • video
  • Number:
    • decimal
    • float
    • integer
  • Paragraphs
  • Taxonomy
  • Telephone
  • Text:
    • plain
    • plain, long
    • formatted
    • formatted, long
    • formatted, long, with summary
  • Timestamp
• files:
  • public stream wrapper
  • private stream wrapper
  • s3fs stream wrapper (if possible)
  • physical file at the root of a stream wrapper
  • physical file in a subdirectory in a stream wrapper
  • file entity exists but physical file has been deleted
• infinite loop
• multilingual support:
  • pull content in its default language then in another language
  • pull content in a language then in its default language
• server website URL in a subdirectory, example: https://example.com/server_website
• JSON:API Extras:
  • alias in field name

Proposed workflow for the tests:

• the tests create contents, for example articles
• a fake service is used for the HTTP requests.
• a GET request is done on /entity_share and jsonapi/node/article and recursively on all the pages required (relationships, pagination) to get the data and it is stored in the fake service with a mapping URL => JSON data.
• the contents are deleted
• when making HTTP requests. the fake service returns the data corresponding to the URL requested. Therefore it can also be used to store the content of a physical file.

If this workflow is working. No need for another website.

For physical files, only need to delete it before making the requests. And for the case of having a deleted physical file, a special case in the fake service or deleting te file before putting its data in the fake service will be ok.

3: push content entities (even if currently in a POC state on a separated branch, it will be present in the future)

• field types:
  • Boolean
  • Content (entity reference)
  • Comment: currently not supported
  • Date:
    • date and time
    • date only
  • Dynamic entity reference: currently not supported
  • Email
  • File
  • Image
  • Link:
    • internal (with JSON:API Extras field enhancers at this moment)
    • external
  • List:
    • float
    • integer
    • text
  • Media:
    • audio
    • image
    • file
    • remote video
    • video
  • Number:
    • decimal
    • float
    • integer
  • Paragraphs
  • Taxonomy
  • Telephone
  • Text:
    • plain
    • plain, long
    • formatted
    • formatted, long
    • formatted, long, with summary
  • Timestamp
• files:
  • public stream wrapper
  • private stream wrapper
  • s3fs stream wrapper (if possible)
  • physical file at the root of a stream wrapper
  • physical file in a subdirectory in a stream wrapper
  • file entity exists but physical file has been deleted
• multilingual support:
  • push content in its default language then in another language
  • push content in a language then in its default language
• JSON:API Extras:
  • alias in field name

Proposed workflow for the tests:

• the tests create contents, for example articles
• the contents are loaded into variables with a mapping UUID => object
• a fake service is used for loading entities when needed (for recursion and relationships for example). This will need to rework the POC on 8.x-1.x-push_form to have services mockable or swappable for the tests.
• the contents are deleted. Maybe add an event listener on kernel.request that is enough early to delete content on the fly?

If this workflow is working. No need for another website.

For physical files, only need to delete it before making the requests, as the data could be stored in a variable.

For running automated tests locally it would be easier to mock requests and responses.

Also if DrupalCI prevents having two websites running, avoiding to mirror the project on another platform to have travis or gitlab CI will be better because such setup would prevent being able to run tests locally and automatically in Drupal issue queue.

I will test the mock approach before further investigation on the two websites setup. I would like to avoid this solution.

Tests initialized!

https://www.drupal.org/node/2462927/qa

Updating issue summary.

Add metatag field type to test.

Add #3059916: Missing resource identifier results in TypeError

Try to debug CI.

Add a bunch of tests.

Add cases to test.

Tagging.

Add cases for non translatable entities and bundle.

Also, I discovered writting tests that due to the mechanism preventing infinite loop, it is currently impossible to import the same entity in different language during the same process execution.

Issue about comment 32 created #3064794: Allows to import entities in several languages during the same process.

Add links to child issues and add date range field.

Remove links to issues in the push feature. Not implemented yet.

Add links to dedicated issue for testing channels with filters, sorts and group of filters.

Test UI for async features later.

Marking the issue has fixed has all the remaining test case have dedicated issues.