Drupal Quality Control & Assurance 5 — Questions and Answers
Question 1: What is the role of a 'test fixture' in Drupal automated testing?
- Pre-created content, configuration, or data used to set up a known state for tests (Correct answer)
- A module that mocks third-party API responses
- A YAML file that declares which test classes belong to a test group
- A Drush command that seeds the database with random content
Correct answer: Pre-created content, configuration, or data used to set up a known state for tests
Test fixtures establish a deterministic starting state (nodes, users, config) so that each test runs against consistent data and produces reproducible results.
Question 2: Which Drupal security hardening check should QA verify is enabled on a production site to prevent text injection via user input fields?
- Filtering user input through an allowed HTML text format with XSS filtering enabled (Correct answer)
- Setting the PHP memory limit above 256MB
- Enabling the Drupal shield module
- Configuring trusted host patterns in settings.php
Correct answer: Filtering user input through an allowed HTML text format with XSS filtering enabled
Drupal's text format system with XSS filtering strips disallowed HTML tags from user input, preventing cross-site scripting attacks through content fields.
Question 3: In a Drupal project using GitLab CI, what artifact should the PHPUnit test stage produce to allow QA review of test results?
- A JUnit XML report file consumed by GitLab's test reports UI (Correct answer)
- A plain text log file emailed to the QA team
- A Drupal watchdog export in CSV format
- A code coverage badge only
Correct answer: A JUnit XML report file consumed by GitLab's test reports UI
PHPUnit can output JUnit XML via `--log-junit`, which GitLab CI's `reports: junit:` artifact key parses to display test pass/fail directly in merge request pipelines.
Question 4: A QA team finds that a Drupal cron job silently fails without logging errors. What is the best practice fix?
- Wrapping cron logic in try/catch blocks that log errors to Drupal's watchdog (Correct answer)
- Disabling the cron job until it is manually tested
- Setting the cron interval to once per week to reduce failure frequency
- Moving the cron logic to a hook_form_submit callback instead
Correct answer: Wrapping cron logic in try/catch blocks that log errors to Drupal's watchdog
Catching exceptions in cron implementations and logging them via \Drupal::logger() ensures failures are surfaced and actionable rather than silently swallowed.
Question 5: What does `PHPStan` with the `phpstan/phpstan-drupal` extension add to a Drupal project's quality pipeline?
- Static type analysis that catches type errors and undefined method calls without running the code (Correct answer)
- Performance profiling of Drupal hooks at runtime
- Automated generation of PHPDoc blocks for missing annotations
- Validation of Drupal routing YAML files for syntax errors
Correct answer: Static type analysis that catches type errors and undefined method calls without running the code
phpstan-drupal extends PHPStan with Drupal-specific stubs and rules so that static analysis understands Drupal's service container, entity APIs, and hook system during type checking.
Question 6: Which strategy should a QA team adopt to validate that a Drupal site's Views-generated pages remain correct after a database schema change?
- Automated functional tests that assert specific field values appear in the rendered view output (Correct answer)
- Manually browsing each view page after the schema change
- Exporting the view configuration to YAML and diffing it against a baseline
- Running `drush cr` and checking the Drupal status report
Correct answer: Automated functional tests that assert specific field values appear in the rendered view output
Functional tests that render views and assert expected field values in the HTML output will immediately fail if a schema change causes a view query to break or return unexpected data.
Question 7: What is the purpose of the Drupal `upgrade_status` module in a QA workflow?
- Scanning installed modules and themes for compatibility with the next major Drupal version (Correct answer)
- Automatically upgrading Drupal core to the latest release
- Checking module update hooks for upgrade path completeness
- Validating that all contrib modules are from the official drupal.org repository
Correct answer: Scanning installed modules and themes for compatibility with the next major Drupal version
The upgrade_status module analyzes installed projects for deprecated API usage and flags those that need updates before a major Drupal version migration, giving QA teams a readiness checklist.
What is the role of a 'test fixture' in Drupal automated testing?