Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better tests #135

Open
jonathanjfshaw opened this issue Jul 30, 2017 · 1 comment
Open

Better tests #135

jonathanjfshaw opened this issue Jul 30, 2017 · 1 comment

Comments

@jonathanjfshaw
Copy link
Contributor

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:

  1. A working Drupal installation
  2. The code from the Driver PR
  3. 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:

  "autoload": {
    "psr-0": {
      "Drupal\\Drupal": "src/",
      "Drupal\\Exception": "src/",
      "Drupal\\DrupalExtension": "src/"
    }

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:

  1. 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.
  2. Use Drush to install Drupal in a subfolder
  3. 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
  4. Use php unit to run kernel-like tests

Does this all seem like a good direction to go in?

@jonathanjfshaw
Copy link
Contributor Author

Kernel tests introduced in #157, although not yet a good way of running them on Travis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant