java-debugger.yaml

# Test Plan: Debugger for Java (from vscode-java-pack.wiki)
#
# Source: wiki Test-Plan.md "Debugger for Java" scenario
# Verify: Start debug → breakpoint hit → step through → inspect variables → program output
#
# Uses the simple-app project (App.java with a main method)
#
# Prerequisites:
#   - vscode-java repo is cloned locally
#   - JDK is installed and available
#
# Usage: autotest run test-plans/java-debugger.yaml

name: "Java Debugger — Breakpoint Debugging"
description: |
  Corresponds to the Debugger for Java scenario in the wiki Test Plan:
  Open the simple-app project, set a breakpoint, start debugging,
  and verify breakpoint hit and program output.

setup:
  extension: "redhat.java"
  extensions:
    - "vscjava.vscode-java-pack"
  vscodeVersion: "stable"
  workspace: "../../vscode-java/test/resources/projects/eclipse/simple-app"
  timeout: 60

steps:
  # ── Remove files that cause compilation errors ──────────
  # simple-app has Bar.java and Foo.java with unresolved references
  # Delete them so App.java compiles cleanly for debugging
  - id: "delete-bar"
    action: "deleteFile src/app/Bar.java"

  - id: "delete-foo"
    action: "deleteFile src/app/Foo.java"

  # ── Wait for LS ready ────────────────────────────────────
  # verify text describes the persistent Problems panel state, not the
  # transient status-bar text which can flicker into Building/Searching
  # right after Ready (Maven post-import incremental compile).
  - id: "ls-ready"
    action: "waitForLanguageServer"
    verify: "Java workspace has loaded; Problems panel shows no errors"
    verifyProblems:
      errors: 0
    skipLlmVerify: true  # waitForLanguageServer is authoritative; LLM only sees the same status bar
    timeout: 120

  # ── Open App.java ────────────────────────────────────────
  - id: "open-app"
    action: "open file App.java"
    verify: "App.java file is opened in the editor"
    waitBefore: 5
    timeout: 15

  # ── Set breakpoint ───────────────────────────────────────
  # App.java line 5: System.out.println("Hello Java");
  - id: "set-breakpoint"
    action: "setBreakpoint 5"
    verify: "Red breakpoint dot is shown in the gutter of App.java line 5"

  # ── Start debug session ─────────────────────────────────
  - id: "start-debug"
    action: "startDebugSession"
    verify: "Debug session has started; the debug toolbar (continue / step / stop) is visible"
    timeout: 30

  # ── Verify breakpoint hit ───────────────────────────────
  # wiki: "verify if the breakpoint is hit". The deterministic ground
  # truth is the next step `debugStepOver` — it can only succeed if the
  # debugger is paused. The verify text is intentionally lenient: the
  # yellow execution-line marker can be off-viewport when the debug
  # toolbar pushes the editor down, so we accept either the marker or
  # the debug toolbar in paused state as evidence.
  - id: "verify-breakpoint"
    action: "wait 10 seconds"
    verify: "Program is paused at the breakpoint — debug toolbar visible in paused state or the yellow execution-line marker appears on/near App.java line 5"

  # ── Continue execution ──────────────────────────────────
  - id: "continue-debug"
    action: "debugStepOver"
    verify: "Program has stepped one statement and remains paused (debug toolbar still in paused state)"

  # ── Stop debug ──────────────────────────────────────────
  - id: "stop-debug"
    action: "stopDebugSession"
    verify: "Debug session has ended; the debug toolbar is no longer visible"