Better bootstrap refactor #3820
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ences to any external Drush classes from boot object; keep Drupal bootstrap state only.
… bootstrap manager, so that we can save all state about the bootstrapped site in the bootstrap object. If this worked, then we would be able to run the Drush preflight multiple times in the integration tests, and re-inject the bootstrap object to recapture the 'state' of the Drupal bootstrap. There are two impediments to this: 1. we inject the Drupal-dependent commands as part of the bootstrap. 2. we inject a Drush logger object into Drupal. These problems might be overcome with further refactoring, but I am not going to continue with this experiment for the time being.
… tests now that bootstrap object is cached, and preflight is done for every call to Drush.
weitzman
approved these changes
Dec 10, 2018
tests/README.md
Outdated
| - Unit tests operate on functions that take values and return results without creating side effects. No database connection is required to run these tests, and no Drupal site is set up. | ||
| - Integration tests set up a test dependency injection container and operate by calling the Symfony Application APIs directly. A Drupal site called the System Under Test is set up and used for the tests. The SUT is set up and installed only once, and then is re-used for all tests. Integration tests therefore cannot make destructive changes to the SUT database. Also, Drupal is bootstrapped only once (always using the standard Drupal kernel, never the install or update kernel), and the Drush preflight runs only once. This means that all commands run at BOOTSTRAP_FULL, and it is not possible to test loading different Drush configuration files and so on. It is not possible to test backend mode or argument / option parsing. The shutdown and error handlers are not installed, so PHP deprecation warnings will be evidenced in the integration tests. | ||
| - Integration tests set up a test dependency injection container and operate by calling the Symfony Application APIs directly. A Drupal site called the System Under Test is set up and used for the tests. The SUT is set up and installed only once, and then is re-used for all tests. Integration tests therefore cannot make destructive changes to the SUT database. Also, Drupal is bootstrapped only once (always using the standard Drupal kernel, never the install or update kernel). This means that all commands run at BOOTSTRAP_FULL, and it is not possible to test loading different Drush configuration files and so on. It is not possible to test backend mode or argument / option parsing. The shutdown and error handlers are not installed, so PHP deprecation warnings will be evidenced in the integration tests. | ||
| - Functional tests operate by `exec`ing the Drush executable. All functional tests therefore run in their own separate processes. The Drupal System Under Test is set up every time it is needed by any functional test. It is therefore okay if a functional test changes the state of the SUT. |
Member
There was a problem hiding this comment.
The Drupal System Under Test is set up every time it is needed by any functional test. It is therefore okay if a functional test changes the state of the SUT.
I would say "...is installed every time ... changes the state of the database." The SUT codebase is reused so its fine to change te DB but not the codebase.
Member
Author
There was a problem hiding this comment.
It is possible to change the codebase in non-destructive ways, e.g. to add the woot module. However, it is my thought that we should just add the woot module and the SUT site aliases to the repository, and not copy them in every time.
Member
There was a problem hiding this comment.
Well, I think test should clean up after themselves when they do enable a module.
- OK to enable woot to the SUT.
- I think the issue with adding site aliases is that they have full paths and those won't be the same on everyone's machine.
| * 'dev' and 'stage', and bootstrap Drupal ONCE. All integration tests | ||
| * will run in this same bootstrapped environment in the same phpunit | ||
| * process, and must not do anything to damage or alter it. | ||
| * UnishIntegrationTestCase will prepare a single of Drupal site, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuation of #3815