You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like we could really do with better tests in the Driver. In particular, tests that show that the desired results are actually performed on Drupal.
This could involves two types of tests:
Kernel tests
Something a bit like D8's kernel tests. At it's simplest this could just be PHP unit tests that call out to the \Drupal container to interrogate the Drupal API.
Extension features
One low hanging fruit might be to run the Drupal extension's @api features on every Driver PR. They're the most complete test suite of expected Driver functionality we currently have.
The challenge
In both cases, I think we need to combine 3 things:
A working Drupal installation
The code from the Driver PR
An autoloader that works well enough for the Driver to reach Drupal
The Drupal Extension does something similar for its tests. I think what it does depends on this magic in this composer.json used in the tests:
I think this is making classes in the /src folder in travis' root available in the namespace Drupal\DrupalExtension. I suspect this effectively makes it available as a pseudo-package as if it had been composer-required. We should be able to use a similar trick with the Driver. That's how we get the code form the Driver's PR (automatically loaded by Travis into the root folder) to be available as if it was installed in a Drupal project normally.
Would this be enough so that we could make calls like \Drupal::entityTypeManager() from within a Driver test class in tests/Drupal/Tests/Driver invoked by php unit?
If so the basic picture would be:
Have a composer.json.dist requiring the drupal extension and with additional autoload parameters similar to the above for the driver; copy this to composer.json and run composer install.
Use Drush to install Drupal in a subfolder
Copy the various Drupal extension features etc. files out of the extension to where they would be in a normal Drupal project, and set up those Behat tests to run
Use php unit to run kernel-like tests
Does this all seem like a good direction to go in?
The text was updated successfully, but these errors were encountered:
It seems like we could really do with better tests in the Driver. In particular, tests that show that the desired results are actually performed on Drupal.
This could involves two types of tests:
Kernel tests
Something a bit like D8's kernel tests. At it's simplest this could just be PHP unit tests that call out to the \Drupal container to interrogate the Drupal API.
Extension features
One low hanging fruit might be to run the Drupal extension's @api features on every Driver PR. They're the most complete test suite of expected Driver functionality we currently have.
The challenge
In both cases, I think we need to combine 3 things:
The Drupal Extension does something similar for its tests. I think what it does depends on this magic in this composer.json used in the tests:
I think this is making classes in the /src folder in travis' root available in the namespace Drupal\DrupalExtension. I suspect this effectively makes it available as a pseudo-package as if it had been composer-required. We should be able to use a similar trick with the Driver. That's how we get the code form the Driver's PR (automatically loaded by Travis into the root folder) to be available as if it was installed in a Drupal project normally.
Would this be enough so that we could make calls like \Drupal::entityTypeManager() from within a Driver test class in tests/Drupal/Tests/Driver invoked by php unit?
If so the basic picture would be:
Does this all seem like a good direction to go in?
The text was updated successfully, but these errors were encountered: