Quiz: Debugging with Xdebug

debugging-with-xdebug.json

{
  "quizzes": [
    {
      "title": "Debugging with Xdebug",
      "passingScore": 70,
      "timeLimit": 0,
      "maxAttempts": 0,
      "allowRetakes": 1,
      "showCorrectAnswers": 1,
      "shuffleQuestions": 1,
      "shuffleAnswers": 1,
      "hasGuestAccess": 0,
      "hasFreeAccountAccess": 0,
      "enabled": 1,
      "multipleChoiceQuestions": [
        {
          "questionText": "In the Xdebug debugging architecture, which component acts as the client and which acts as the server?",
          "quizOptions": [
            { "optionText": "Your IDE is the client; Xdebug is the server", "isCorrect": 0 },
            { "optionText": "Both act as clients connecting to a central debug server", "isCorrect": 0 },
            { "optionText": "Xdebug is the client; your IDE is the server", "isCorrect": 1 },
            { "optionText": "The web browser is the client; Xdebug is the server", "isCorrect": 0 }
          ],
          "explanation": "Xdebug is the client that initiates the connection. Your IDE (PhpStorm or VS Code) passively listens on a port, waiting for Xdebug to connect — the opposite of what most people expect."
        },
        {
          "questionText": "What port does Xdebug 3 use by default to connect to your IDE?",
          "quizOptions": [
            { "optionText": "9000", "isCorrect": 0 },
            { "optionText": "9003", "isCorrect": 1 },
            { "optionText": "8080", "isCorrect": 0 },
            { "optionText": "3000", "isCorrect": 0 }
          ],
          "explanation": "Xdebug 3 uses port 9003 by default. Earlier versions used port 9000. Your IDE must be configured to listen on this port for incoming debug connections."
        },
        {
          "questionText": "What DDEV command enables Xdebug in your development container?",
          "quizOptions": [
            { "optionText": "ddev debug enable", "isCorrect": 0 },
            { "optionText": "ddev php xdebug on", "isCorrect": 0 },
            { "optionText": "ddev xdebug enable", "isCorrect": 1 },
            { "optionText": "ddev config --xdebug", "isCorrect": 0 }
          ],
          "explanation": "DDEV has built-in support for toggling Xdebug with ddev xdebug enable and ddev xdebug disable. This enables or disables the Xdebug PHP extension in the Docker container."
        },
        {
          "questionText": "If PhpStorm is not listening for debug connections when Xdebug tries to connect, what happens?",
          "quizOptions": [
            { "optionText": "An error is displayed in the browser", "isCorrect": 0 },
            { "optionText": "Xdebug moves on silently and PHP executes normally", "isCorrect": 1 },
            { "optionText": "PHP throws a fatal error", "isCorrect": 0 },
            { "optionText": "Xdebug retries the connection every 5 seconds", "isCorrect": 0 }
          ],
          "explanation": "If the IDE isn't listening, Xdebug simply can't connect and moves on. PHP executes normally with no error or warning — this is the classic \"I set everything up but nothing happens\" scenario."
        },
        {
          "questionText": "What is a breakpoint in step debugging?",
          "quizOptions": [
            { "optionText": "A syntax error that stops code execution", "isCorrect": 0 },
            { "optionText": "A log statement that outputs variable values", "isCorrect": 0 },
            { "optionText": "A marker that tells the debugger to pause execution at a specific line", "isCorrect": 1 },
            { "optionText": "A point where the application crashes", "isCorrect": 0 }
          ],
          "explanation": "A breakpoint is a marker you set in your IDE that tells the debugger to pause execution at that specific line. When execution reaches a breakpoint, you can inspect variables, the call stack, and step through code."
        },
        {
          "questionText": "When should you use \"Step Into\" during a debugging session?",
          "quizOptions": [
            { "optionText": "When you want to skip over a function call entirely", "isCorrect": 0 },
            { "optionText": "When you want to enter a function to see what happens inside it", "isCorrect": 1 },
            { "optionText": "When you want to resume execution until the next breakpoint", "isCorrect": 0 },
            { "optionText": "When you want to exit the current function immediately", "isCorrect": 0 }
          ],
          "explanation": "Step Into enters a function call so you can see what happens inside it. Use it when a function returns unexpected results and you need to trace the internal logic — like stepping into $entry->validate() to find which validation rule is failing."
        },
        {
          "questionText": "What is the difference between \"Step Over\" and \"Step Into\"?",
          "quizOptions": [
            { "optionText": "Step Over runs the entire program; Step Into pauses at every line", "isCorrect": 0 },
            { "optionText": "Step Over skips breakpoints; Step Into respects them", "isCorrect": 0 },
            { "optionText": "Step Over executes the current line without entering function calls; Step Into enters them", "isCorrect": 1 },
            { "optionText": "There is no difference; they are aliases", "isCorrect": 0 }
          ],
          "explanation": "Step Over executes the current line and any function calls on it without entering those functions — you see the return value but not the internal execution. Step Into enters the function so you can debug its internals line by line."
        },
        {
          "questionText": "What does the call stack show you during a debugging session?",
          "quizOptions": [
            { "optionText": "A list of all variables in the current scope", "isCorrect": 0 },
            { "optionText": "A list of all breakpoints set in the project", "isCorrect": 0 },
            { "optionText": "The HTTP request headers", "isCorrect": 0 },
            { "optionText": "The chain of function calls that led to the current execution point", "isCorrect": 1 }
          ],
          "explanation": "The call stack shows every function that was called to reach the current point, in order, with their parameters. It helps you understand how deep you are in the framework, identify recursive calls, and trace the request lifecycle."
        },
        {
          "questionText": "What is the purpose of \"Watches\" in a debugger?",
          "quizOptions": [
            { "optionText": "To time how long each function takes to execute", "isCorrect": 0 },
            { "optionText": "To monitor variables or expressions continuously as you step through code", "isCorrect": 1 },
            { "optionText": "To record a video of the debugging session", "isCorrect": 0 },
            { "optionText": "To watch for new HTTP requests", "isCorrect": 0 }
          ],
          "explanation": "Watches let you monitor specific variables or expressions (like count($results) or $user->can('edit', $entry)) as you step through code. Their values update at each step, making it easy to spot when something changes unexpectedly."
        },
        {
          "questionText": "What VS Code extension is required to debug PHP with Xdebug?",
          "quizOptions": [
            { "optionText": "PHP Intelephense", "isCorrect": 0 },
            { "optionText": "PHP Tools", "isCorrect": 0 },
            { "optionText": "PHP Debug (php-debug) by Felix Becker", "isCorrect": 1 },
            { "optionText": "Xdebug Helper", "isCorrect": 0 }
          ],
          "explanation": "The php-debug extension by Felix Becker provides the debugging interface in VS Code for Xdebug. It enables setting breakpoints, inspecting variables, and stepping through PHP code via the Debug panel."
        },
        {
          "questionText": "What is the purpose of the launch.json file in VS Code for Xdebug?",
          "quizOptions": [
            { "optionText": "It installs Xdebug on the server", "isCorrect": 0 },
            { "optionText": "It defines debugging configurations including port and path mappings", "isCorrect": 1 },
            { "optionText": "It stores breakpoint locations between sessions", "isCorrect": 0 },
            { "optionText": "It configures PHP syntax highlighting", "isCorrect": 0 }
          ],
          "explanation": "The launch.json file tells the VS Code debugger which debugging configurations to use. For Xdebug, it specifies the hostname, port (9003), and path mappings between the server paths and your local workspace."
        },
        {
          "questionText": "Why do breakpoints sometimes fail to trigger even when Xdebug connects successfully?",
          "quizOptions": [
            { "optionText": "The breakpoints were set in the wrong programming language", "isCorrect": 0 },
            { "optionText": "The PHP version is too old", "isCorrect": 0 },
            { "optionText": "Path mapping is wrong — the IDE and Xdebug disagree on file paths", "isCorrect": 1 },
            { "optionText": "Breakpoints only work in production environments", "isCorrect": 0 }
          ],
          "explanation": "When path mapping is incorrect, your IDE looks for a file at one path (e.g., /Users/you/project/web/index.php) while Xdebug reports a different path (e.g., /var/www/html/web/index.php). They're talking past each other, so breakpoints don't match."
        },
        {
          "questionText": "What is the \"Evaluate Expression\" feature used for during debugging?",
          "quizOptions": [
            { "optionText": "Evaluating the performance of your code", "isCorrect": 0 },
            { "optionText": "Compiling PHP expressions into bytecode", "isCorrect": 0 },
            { "optionText": "Running arbitrary code in the current execution context without changing source files", "isCorrect": 1 },
            { "optionText": "Evaluating whether the code follows PSR standards", "isCorrect": 0 }
          ],
          "explanation": "Evaluate Expression lets you run arbitrary code in the current context — test fixes without changing files, call methods like $service->clearCache(), or inspect computed values like json_decode($response->getBody(), true)."
        }
      ],
      "trueFalseQuestions": [
        {
          "questionText": "Xdebug debugs every PHP request by default without any trigger.",
          "correctAnswer": 0,
          "explanation": "Xdebug doesn't debug every request — that would kill performance. It looks for a trigger, typically a special cookie, query parameter, or configuration setting, before initiating a debug session."
        },
        {
          "questionText": "In DDEV, the path mapping for Xdebug should map your local project root to /var/www/html on the container.",
          "correctAnswer": 1,
          "explanation": "DDEV maps your project files to /var/www/html inside the Docker container. Your IDE needs this path mapping so it can match the file paths Xdebug reports from the container to your local files."
        },
        {
          "questionText": "Xdebug 3 has minimal performance impact and can typically be left enabled during an entire development session.",
          "correctAnswer": 1,
          "explanation": "Xdebug 3 is significantly faster than previous versions. The course notes that there's no noticeable lag when running on DDEV, and you can keep it enabled during development without performance concerns."
        },
        {
          "questionText": "The \"Step Out\" action skips all remaining code in the program and ends the debugging session.",
          "correctAnswer": 0,
          "explanation": "Step Out runs until the current function returns, then pauses in the calling code. It doesn't end the session — it's useful when you accidentally stepped into a function and want to get back to the calling context."
        }
      ],
      "codeChallengeQuestions": [
        {
          "questionText": "What does this VS Code launch.json configuration do?",
          "codeSnippet": "{\n    \"name\": \"Listen for XDebug\",\n    \"type\": \"php\",\n    \"request\": \"launch\",\n    \"hostname\": \"0.0.0.0\",\n    \"port\": 9003,\n    \"pathMappings\": {\n        \"/var/www/html\": \"${workspaceRoot}\"\n    }\n}",
          "codeLanguage": "json",
          "quizOptions": [
            { "optionText": "Starts an Xdebug server on port 9003", "isCorrect": 0 },
            { "optionText": "Connects VS Code to a remote PHP server via SSH", "isCorrect": 0 },
            { "optionText": "Configures VS Code to listen on port 9003 and map container paths to local workspace paths", "isCorrect": 1 },
            { "optionText": "Installs Xdebug on the Docker container", "isCorrect": 0 }
          ],
          "explanation": "This configuration tells VS Code to listen on port 9003 for incoming Xdebug connections. The pathMappings entry maps /var/www/html (the project path inside the Docker container) to ${workspaceRoot} (your local project directory) so breakpoints align correctly."
        },
        {
          "questionText": "What is wrong with this PhpStorm path mapping for a DDEV project?",
          "codeSnippet": "Local path:     /Users/ryan/project/web\nServer path:    /var/www/html/web",
          "codeLanguage": "shell",
          "quizOptions": [
            { "optionText": "The local path should use forward slashes", "isCorrect": 0 },
            { "optionText": "The mapping should be at the project root, not the web directory", "isCorrect": 1 },
            { "optionText": "The server path should be /app instead", "isCorrect": 0 },
            { "optionText": "Path mappings are not needed for DDEV", "isCorrect": 0 }
          ],
          "explanation": "Mapping only the web directory means PhpStorm can't find application files outside of web/ (like plugins, modules, and config). The correct mapping is the project root directory to /var/www/html so all code files are accessible for debugging."
        }
      ]
    }
  ]
}